Release notes: Banking.Live 3.8

---

AUTH-1952: Changes to Merchant Category Codes

Banking.Live now supports newly introduced Merchant Category Codes (MCCs) and associated merchant names as part of the April 2026 VisaNet Business Enhancements. This update introduces new MCC values 3305 and 3854–3883, related to airline and hotel merchant categories, enabling the platform to recognise and classify transactions from these merchants correctly.

Applicability

Enablement

Support for the new MCC values has been implemented by inserting the required entries into the MCC reference tables. Verification was also performed to confirm that existing MCCs 6050, 6051, and 5262 are present in the database. No client configuration or enablement is required.

Technical info

The following technical updates were implemented:

• Added new MCC entries 3305 and 3854–3883 with corresponding MCC groups, merchant names, and required merchant names.
• These values may appear in VisaNet transaction messages

AUTH-1968: Changes to Visa B2B Payment Controls Processing for Issuers

Banking.Live now supports the two-byte length format for TLV fields in Data Elements 111 and 125 (Usage 2) used in Visa authorization messages. This enhancement ensures that the platform can correctly parse TLV-formatted transaction data when the field length is encoded using either one-byte or two-byte binary length values. The update supports Visa’s enhancements to Visa B2B Payment Controls, which introduce new datasets and tags in TLV Field 125, Usage 2 for improved authorization decisioning and decline transparency.

Applicability

Enablement

Support for two-byte TLV length parsing has been implemented in the authorization message processing logic. The platform now supports both one-byte and two-byte length formats for the TLV length subfield when parsing DE111 and DE125 (Usage 2). No client configuration or enablement is required.

Technical info

The following technical updates were implemented:

• Enhanced TLV parsing logic to support one-byte and two-byte binary length subfields
• The length subfield represents the total number of bytes contained in the TLV field, including dataset IDs, dataset lengths, and TLV elements.
• The system now successfully processes messages where: DE111 is received with 1-byte or 2-byte length indicators DE125 (Usage 2) is received with 1-byte or 2-byte length indicators
• These updates support Visa’s enhancements for Visa B2B Payment Controls, including the ability to receive new dataset IDs and tags in TLV Field 125, Usage 2 for authorization and advice messages.

CBK-279: Revised Standards for Expanding the First-Party Trust Program to Brazil

Banking.Live has been enhanced to support Mastercard’s First-Party Trust Program. These updates allow the platform to correctly process and manage chargebacks rejected by Mastercard as First-Party Fraud. When Mastercard rejects a 4837 – No Cardholder Authorisation chargeback under the First-Party Trust program, Banking.Live will now log the rejection using Reject Reason Code 5002 and ensure the dispute can be tracked and managed through the appropriate lifecycle stages. The platform also introduces additional data fields and reporting updates required by Mastercard, enabling clients to review rejected disputes, assess the supporting documentation provided by issuers, and proceed with representment when appropriate. This update ensures that Paymentology clients operating in Brazil and Latin America remain compliant with Mastercard’s evolving dispute management standards. Clients will benefit from: Improved visibility into disputes rejected as First-Party Fraud Clear identification of cases that require acquirer action The ability to challenge invalid chargeback rejections when issuer documentation is incomplete or incorrect Enhanced reporting and reconciliation aligned with Mastercard dispute lifecycle requirements These capabilities help clients manage disputes more effectively while maintaining compliance with Mastercard rules.

Applicability

Enablement

The new functionality is automatically enabled within Banking.Live dispute processing. No configuration changes are required by clients. Clients participating in the Mastercard First-Party Trust program should ensure their dispute teams are familiar with the updated workflow: Review chargebacks rejected with Reason Code 5002. Assess the issuer documentation and evidence provided. If the documentation is incomplete or invalid, submit a representment using Reason Code 2713 – Invalid Chargeback. Continue the dispute lifecycle through standard pre-arbitration and arbitration processes if required These updates also introduce internal enhancements to dispute monitoring and reporting to ensure full compliance with Mastercard processing and reconciliation requirements.

Technical info

NA.

---

PECA-941: Clarified PaySecure RSA-OAEP SHA-512 Encryption Requirements

PaySecure documentation has been updated to clearly outline the required RSA-OAEP with SHA-512 encryption configuration for Banking.Live 3.x environments. The updated guidance includes improved examples, clearer parameter definitions, and migration notes for clients transitioning from legacy hashing configurations. These updates help ensure encryption is implemented correctly during integration and environment setup. This update reduces integration issues and support overhead by helping clients configure encryption correctly, supporting smoother go-lives while maintaining strong security for cardholder data..

Applicability

Enablement

Clients integrating with PaySecure in Banking.Live 3.x environments should review the updated documentation before performing integration testing or enabling encryption in their environments.

Technical info

PaySecure API Security – RSA Encryption (Developer Portal) https://developer.paymentology.com/bankinglive/docs/security-paysecure-api#v1-session-id-rsa-encryption-for-generating-session-id-java-example

PECA-905: PaySecure Encryption Update – RSA-OAEP with SHA-512 for Banking.Live 3.x

PaySecure client-facing behaviour and documentation have been updated to align with the RSA-OAEP with SHA-512 encryption baseline introduced as part of the Banking.Live 3.x cryptography uplift. The updated guidance clarifies the required encryption parameters, expected runtime behaviour, and migration considerations for clients integrating with PaySecure. Clients gain clear, accurate guidance on how to configure RSA-OAEP SHA-512 encryption when integrating with PaySecure, reducing misconfiguration risk, test failures, and rollout delays. Cardholder data benefits from a stronger cryptographic posture without requiring any change to the end-user experience.

Applicability

Enablement

Clients integrating with PaySecure in Banking.Live 3.x environments should review the updated encryption requirements and ensure their implementations comply before performing integration testing or enabling production environments.

Technical info

PaySecure API Security – RSA Encryption (Developer Portal) https://developer.paymentology.com/bankinglive/docs/security-paysecure-api#v1-session-id-rsa-encryption-for-generating-session-id-java-example

AUTH-1566: Enhanced Merchant-Initiated Transaction (MIT) Identification Using DE48 SE22 SF5

Banking.Live has enhanced the logic used to identify Merchant-Initiated Transactions (MITs). When the Exemption Flag in DE48 SE22 SF1 is not set to values 1 or 3, the system will now evaluate DE48 SE22 SF5. If SF5 contains a value in the format Mxxx, the transaction will be identified as an MIT. This update ensures MIT identification logic has been enhanced.

Applicability

Enablement

The enhanced MIT identification logic is automatically enabled within Banking.Live. No client configuration or enablement is required.

Technical info

NA.

AUTH-1768: Token ATC tracking and Validation

Paymentology has introduced Application Transaction Counter (ATC) tracking and validation for EMV tokenized transactions. With this enhancement, the Authorization Engine compares the incoming ATC value from a tokenized transaction against the previously stored ATC value associated with the token. This allows the system to detect anomalies such as repeated or out-of-sequence ATC values that could indicate potential fraud or replay attempts. This validation applies to tokenized wallet transactions (for example Apple Pay or Google Pay) where EMV cryptographic data is available. This feature provides an additional layer of security for tokenized transactions. By validating the ATC value, issuers can detect suspicious transaction patterns and reduce the risk of fraudulent or replayed token transactions.

Applicability

Enablement

Clients can optionally enable this validation to strengthen fraud detection for digital wallet payments. The feature is controlled via a product setting, allowing clients to select one of the following modes: Decline Transaction The transaction will be declined if the ATC value is invalid or out of sequence. Log Only ATC mismatches will be logged for monitoring purposes but will not affect the transaction decision. Ignore ATC for Wallet Transactions (Default) No ATC validation is performed for tokenized wallet transactions. To enable the feature, clients can contact Support and request for product setting parameter tokenized_atc_validation_mode = 1 to be set.

Technical info

NA.

CBK-318: Enhanced Processing of Mastercard Pre-Arbitration and Arbitration Events

Banking.Live has enhanced its dispute processing capabilities to improve how Mastercard Pre-Arbitration and Arbitration events are matched to existing dispute records. With this enhancement, additional dispute identifiers are now retained and used when processing incoming Mastercard T140 (IP142110-AA) messages. This enables the platform to more accurately associate Pre-Arbitration and Arbitration events with the correct dispute lifecycle records and settlement data. The update ensures that dispute events can still be correctly linked even in cases where earlier stages of the dispute lifecycle were processed outside of Banking.Live.

Applicability

Enablement

The enhanced dispute matching capability is automatically enabled within Banking.Live. No client configuration or integration changes are required.

Technical info

NA.

PECR-957: ABU File Update for Expired Cards

Banking.Live has been updated so that cards that expire during the reporting period are now included in the ABU output file as closed records. Previously, expired cards were not included in the ABU output. With this enhancement, expired cards will be reported alongside other card status updates, ensuring the card network receives accurate lifecycle updates

Applicability

Enablement

The enhancement is automatically enabled within Banking.Live. No client configuration or integration changes are required.

Technical info

Cards that expire during the reporting period will now be included in the ABU output file. These cards will appear as closed records within the file. The file structure and format remain unchanged. Downstream systems processing ABU files may receive additional closure records reflecting expired cards.

CLR-890: Visa Settlement Processing V2

Banking.Live introduces Visa Settlement Processing V2, an updated settlement processing engine designed to improve the performance, stability, and maintainability of Visa settlement file handling. The new processing approach streams settlement files instead of loading the entire file into memory, improving the platform’s ability to handle large settlement files and reducing the risk of memory-related processing issues. This enhancement improves the overall reliability of Visa settlement processing, helping ensure consistent delivery of settlement and FAST messages to clients. Visa Processing V2 also introduces several additional data fields in Visa FAST settlement messages while maintaining backward compatibility with all existing FAST fields. Clients can continue to process the existing fields as usual and may ignore the new fields if they are not required.

Applicability

Enablement

The feature will first be enabled in UAT environments, allowing clients to validate settlement file processing before production rollout. No integration changes are required.

Technical info

NA.