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

RegionSchemeCard typeProduct
AllMastercardNAProcessing: 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

RegionSchemeCard typeProduct
AllMastercardNAProcessing: 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

RegionSchemeCard typeProduct
AllAllNAProcessing-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

RegionSchemeCard typeProduct
AllAllNAAPI

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

RegionSchemeCard typeProduct
AllAllNAAPI

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

RegionSchemeCard typeProduct
AllAllNAProcessing - 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.