Release notes: Banking.Live 2.24
AUTH-1137: Update of currency code from ANG to XCG for Curacao and Sint Maarten
The currency code for Curacao and Sint Maarten is changing.
- Old alpha code: ANG (Netherlands Antilles Guilder)
- New alpha code: XCG (Caribbean Guilder)
- Numeric code: 532 (unchanged)
- Decimal places: 2 (unchanged)
This change ensures compliance with the latest currency standards for Curacao and Sint Maarten.
Transactions involving Curacao and Sint Maarten (currency code 532) will now use XCG instead of ANG.
Applicability
| Region | Scheme | Card type | Product |
|---|---|---|---|
| All | All | NA | Processing |
Enablement
Please prepare to receive the new alpha code XCG in the Transaction_Currency and Billing_Currency fields of FAST messages.
Note: this change is present from BL-2.23. Please refer to your production deployment schedule.
Technical info
The Transaction_Currency and Billing_Currency fields are found in the SUMMARY node of FAST request messages:
"Transaction_Currency" : "XCG","Billing_Currency" : "XCG",
AUTH-1138: New Merchant Category Code for Riyadh Air
A new Merchant Category Code (MCC ) 3169 has been introduced for Riyadh Air.
This code has been added to the relevant database to ensure the appropriate description in FAST request messages for this merchant.
Applicability
| Region | Scheme | Card type | Product |
|---|---|---|---|
| All | All | NA | Processing |
Enablement
Please prepare to receive the new MCC 3169 in FAST messages.
Note: this change is present from BL-2.23. Please refer to your production deployment schedule.
Technical info
The Merchant_Category field is found in the SUMMARY node of FAST request messages:
"Merchant_Category" : "3169 - Riyadh Air",
DE18 (Merchant Category Code) is found in the ISO_MSG node of FAST messages:
"DE18" : "3169",
PECA-682: New Mada tokenization client configuration: OTP (Yellow Flow) for app provisioning
In response to SAMA’s regulatory requirements, we have introduced a new client setting that allows Issuers to enforce OTP-based (Yellow Flow) authentication for app provisioning. Previously, app provisioning followed the Green Flow, but now clients can choose to require OTP verification for added security and compliance.
This update gives greater control and flexibility to clients who need to meet regulatory standards, ensuring a secure and compliant provisioning process while improving cardholder protection.
Applicability
| Region | Scheme | Card type | Product |
|---|---|---|---|
| Saudi Arabia | Mada (Tokenization) | Mada tokenized cards | Tokenization (Mada) |
Enablement
If you wish to have this setting enabled, please reach out to your Client Executive or raise a request via our Customer Support Platform.
Technical info
This setting can be enabled at the client level and will apply immediately once activated. If not enabled, provisioning will continue using the Green Flow.
PECA-693: Improved card enrollment reliability with automatic retry mechanism
We have introduced an automatic retry system for card enrollments that fail due to temporary network issues. This enhancement reduces failures and manual intervention by automatically retrying failed enrollment requests using a smart delay strategy.
The feature is configurable and can be enabled for clients who need it. Its benefits include:
- Higher success rates: Failed enrollments will now be automatically retried, improving overall completion rates.
- Less manual work: Reduces the need for support teams to manually reprocess failed enrollments.
- Stronger fraud & compliance protection: Ensures more cards are successfully enrolled in 3D Secure (3DS), reducing fraud risks and maintaining compliance with Mastercard’s data integrity standards (preventing potential fines).
- Automatic recovery from network issues: If an enrollment request fails, the system will retry it automatically instead of requiring manual intervention.
- Flexible configuration: The retry mechanism is not forced on all clients, it can be enabled only for those who need it.
- Smart retry strategy: The system waits longer after each failed attempt to avoid overloading the network.
Applicability
| Region | Scheme | Card type | Product |
|---|---|---|---|
| All | NA | Cards using Paymentology's 3DS solution | 3D Secure: Enrollment |
Enablement
If you wish to have this feature enabled and you’re using Paymentology's 3D Secure solution, please reach out to your Client Executive or raise a request via our Customer Support Platform.
PECP-430: Addition of link to PayControl user guide in PayControl
With the completion of the PayControl User Guide on the Developer Portal, we have added a link to this User Guide within PayControl itself. Increasing usability for PayControl users.
Applicability
| Region | Scheme | Card type | Product |
|---|---|---|---|
| All | NA | NA | PayControl: Documentation |
Enablement
No enablement required.
Technical info
- Under the Documentation sub-menu on PayControl, the main page of the User Guide is linked.
- Instead of the tooltip found on each PayControl page, a link to the specific User Guide page on the Developer Portal is now linked.
- Addition of a tooltip when hovering over a text string revealing more information. For example, you can now hover over a transaction filter to know more about its purpose.
AUTH-1126: Updating reason and response codes for ATC declines
The response code for ATC (Application Transaction Counter) declines has changed from 05 to 63.
Additionally, we have introduced a feature that prevents ATC declines for deferred authorization transactions on Mastercard when the feature flag is enabled.
Applicability
| Region | Scheme | Card type | Product |
|---|---|---|---|
| All | All | NA | Processing: Authorizations |
Enablement
No enablement required for response code changes for ATC declines.
If you wish to have the feature flag enabled that prevents ATC declines for deferred authorization transactions, and you are a Mastercard Issuer, please reach out to your Client Executive or raise a request via our Customer Support Platform.
Technical info
Response code 05 is a general response code, while response code 63 provides a more specific reason.
This change allows clients to access more accurate data when investigating reasons for decline.
You can read more on response codes here.
AUTH-1145: Issuer On-Behalf Services (OBS) 52 check for CVV validation
For tokenized transactions, if we receive OBS 52 (Mastercard Digital Enablement Service CVC 3 Pre-Validation) as valid and the PAN auto-entry via a magnetic stripe or contactless magnetic stripe, CVV validation will be skipped based on the OBS result.
This enhancement improves transaction efficiency by reducing unnecessary CVV checks when Mastercard’s pre-validation service (OBS 52) confirms it’s already valid.
Applicability
| Region | Scheme | Card type | Product |
|---|---|---|---|
| All | Mastercard | Tokenized cards | Processing: Authorizations |
Enablement
No enablement required.
AUTH-1182: Enforce unique card check
As part of enforcing unique card checks for transactions, we have introduced a new Processor_Reason_Code: 131 – Multiple Card Record.
Transactions will be declined with response code (DE39) 05 if multiple records exist for the same card (ECNO).
Applicability
| Region | Scheme | Card type | Product |
|---|---|---|---|
| All | All | NA | Processing: Authorizations |
Enablement
Please prepare to receive the new Processor_Reason_Code and Processor_Reason_Desc.
Technical info
The Processor_Reason_Code and Processor_Reason_Desc fields are found in the SUMMARY node of the FAST request message.
They will display the below details in the event multiple records exist for the same card:
"Processor_Reason_Code" : "131","Processor_Decision_Desc" : "Decline - Multiple Card Record",
DEC-365: Additional transaction values available for whitelisting use in Check Merchant Activity rule
You are now able to whitelist specific values in the Check Merchant Activity Rule, allowing you to bypass the check in the current transaction.
This allows finer controls over the check merchant activity rule.
Applicability
| Region | Scheme | Card type | Product |
|---|---|---|---|
| All | NA | NA | Rules Engine |
Enablement
Please speak with our Fraud Team if you would like to include any whitelisting in the Check Merchant Activity rule.
Technical info
You can specify values related to the fields below:
- Merchant Category Code (MCC) (DE18)
- Acquiring Institution Identification Code (DE32)
- Card Acceptor Terminal Identification (DE41)
- Card Acceptor ID (Merchant ID) (DE42)
- Card Acceptor Name (DE43.1)
- Card Acceptor Country Code (DE43.5)
- Wallet ID/ SLI/ DI/DTI (DE48)
DEFECT-2534: Inclusion of client name in subject line of email notifications
When receiving email notifications from Paymentology Support ([email protected]) regarding file and report generation, the email Subject will now include the client’s name.
Applicability
| Region | Scheme | Card type | Product |
|---|---|---|---|
| All | NA | NA | Email notifications |
Enablement
No enablement required.
Technical info
- Old email Subject: Message From Paymentology ([BL environment name])
- New email Subject: Message From Paymentology: [Client Name] [File/Report Name] ([BL environment name])
Example: Message From Paymentology: Bank101 embossing file transfer (BL 2.0 SHAREDEU-PROD)
