Release notes: Banking.Live 2.28
Auth-1214: Mastercard Mandate: GLB 10432.2 Enhancing Send Data Fields and Name Validation Request (Update)
In line with Mastercard Mandate GLB 10432.2 (Enhancing Send Data Fields and Name Validation Request (Update)), Banking.Live will support validation of cardholder's name during an Account Status Inquiry (ASI) request. The name provided by the registered user can be verified against the name associated with the card at the issuer.
For full details you can refer to Mastercard’s mandate bulletin GLB 10432.2
Applicability
| Region | Scheme | Card type | Product |
|---|---|---|---|
| All | Mastercard | NA | Processing: Authorisations |
Enablement
No enablement required
Technical info
Banking.Live will support;
Full middle name in DE 108 (Additional Transaction Reference Data) subelement 01 (Receiver/Recipient Data), subfield 02 (Receiver/Recipient Middle Name) and DE 108 (Additional Transaction Reference Data) subelement 02 (Sender Data), subfield 02 (Sender Middle Name)
New value of 0 (Normal request [not for Validation request]) and 1 (Validation request) in repurposed DE 61 (Point-of Service [POS] Data), subfield 9 (POS Transaction Status – Extended)
Auth-1210: Mastercard Mandate: Revised Standards for Acceptor Business Codes (MCCs)
In line with Mastercard Mandate GLB 10318.1 (Revised Standards for Acceptor Business Codes (MCCs)), Banking.Live now supports updated MCC description of AIRMALTA to KM Malta Airlines.
For full details you can refer to Mastercard’s mandate bulletin GLB 10318.1
Applicability
| Region | Scheme | Card type | Product |
|---|---|---|---|
| All | Mastercard | NA | Processing: Authorisation |
Enablement
No enablement required
Technical info
Banking.Live now supports the updated name of MCC 3028 from Air Malta: AIRMALTA to KM Malta Airlines: KMMA
DEC-379: Additional logging to the Rules Engine Timing log UI when using Check Merchant Activity rule
We have provided a flag which enables additional logging to the UI when the Check Merchant Activity rule is triggered. Currently when the Check Merchant Activity rule triggers an action - only the current transaction data is available. With the additional logging enabled, current transaction and the previous transactions which led to the rule being triggered will be available.
Applicability
| Region | Scheme | Card type | Product |
|---|---|---|---|
| All | All | NA | Processing-Decision Engine |
Enablement
Please reach out to our fraud team if you would like to enable additional logging to the UI for the Check Merchant Activity rule.
Technical info
If the flag is enabled for the Check Merchant Activity rule and it is triggered - you will see the related transactions in the Rules Engine Timing Log screen.
PECA-742: Card Status Notification added new status: Dynamic Blocking
We have extended our card-status notification framework to cover dynamic block action. Whenever a card’s status_nwk field is changed to 1034 dymanic_block (for example, during a fraud-related dynamic block), Card Status Notification now dispatches a message to the client in real time.
This ensures clients are immediately aware whenever a dynamic block happens on any card, ensuring client systems stay synchronized, allowing support teams to respond without delay.
Applicability
| Region | Scheme | Card type | Product |
|---|---|---|---|
| All | All | NA | API |
Enablement
No enablement required.
Technical info
Notification payloads will reuse the existing FAST CSU schema.
Expect additional CSU notifications each time you invoke (or our rules engine triggers) a dynamic block/unblock.
PECA-764: Standardized ENABLED State for APATA Card Enrollment
We have updated the APATA card enrollment logic to always send the enrollment state as ENABLED. This change addresses prior inconsistencies that led to confusion during card replacement flows when DISABLED was incorrectly used.
This change ensures a more reliable and predictable 3DS enrollment experience during card replacements. By consistently using ENABLED, we eliminate ambiguity for clients who do not differentiate based on APATA’s internal state but rely on enrollment being active.
Applicability
| Region | Scheme | Card type | Product |
|---|---|---|---|
| All | All | NA | API |
Enablement
All future APATA enrollment requests will use the ENABLED state by default.
Technical info
Clients will now receive a consistent ENABLED state during all APATA card enrollments, including replacements. This removes the need to interpret or handle different state values. Functionally, cardholders will experience uninterrupted 3DS enrollment for replacement cards.
AUTH-1213: Configurable Rules Engine Invocation for Tokenization Provisioning Messages
We have introduced a new product-level configuration to control whether Tokenization Provisioning and Token Lifecycle Transaction (TA, TE, TC, AC, TV) messages should be sent to the Rules Engine.
This configuration will allow finer control over Tokenization provisioning messages through Rules Engine.
Applicability
| Region | Scheme | Card type | Product |
|---|---|---|---|
| All | All | NA | Processing - Authorisations |
Enablement
A new field has been added to the Products table. From UI, it’s available under Rules Engine toggle flag.
Technical info
The default behavior is to allow these messages to be sent to the Rules Engine, maintaining current functionality.
