Release notes: Banking.Live 2.29

AUTH-1429: Mastercard Mandate: Introducing Decline Response Code Values

Mastercard is introducing two new response codes in DE39 to improve clarity on decline reasons:
• 46 – Account is closed
• 72 – Account is not activated
In line with Mastercard Mandate GLB 10401.2 (Introducing Decline Response Code Values), we have updated our response logic on Banking.Live to return these codes in 0110 and 0210 messages based on internal account status. Specifically:
• If the account status is 0 (Pre-live Inactive), the system will respond with 72
• If the account status is 3 (Closed), the system will respond with 46
• For all other non-authorized statuses, the fallback response code 57 will be used

This change aligns with Mastercard’s latest messaging guidelines and enhances the precision of our issuer responses. Cardholders and merchants will now receive more specific decline reasons instead of the general- purpose code 57. Mastercard will receive 46 or 72 when applicable, helping reduce confusion and support inquiries.

For full details, you can refer to Mastercard’s Mandate bulletin GLB 10401.2

Applicability

Enablement

No enablement required.

Technical info

NA.

PECA-683: Split Emboss File Output for normal renewal/replacements vs early renewal/replacement Cards

We have introduced a logic to separate the Emboss File output into two distinct files—one for Replacement cards and one for Renewal cards. Banking.Live now checks both the renewal_reason value and the product level feature flag before output is generated.
This change enables clearer downstream processing by personalization bureaus and supports operational alignment for clients who manage these card types through different production and SLA streams.

Applicability

Enablement

If you wish to have this product flag enabled, please contact your account manager.

Technical info

When the feature flag is enabled:
• If a batch includes both normal renewal / replacement and early renewal / replacement cards, two separate Emboss Files are produced.
• The early renewal file receives the suffix _r before being sent to the manufacturer.
• No change to the internal record format—only the file splitting behavior is affected.

PECA-728: MADA: Synchronize Card Art Ref stored locally when updating via Token Update

This update ensures that any new Card Art Reference sent by the client via the Token Update API is now automatically synchronized with our local database. This eliminates discrepancies between the card art stored by MADA and the one returned in CheckEligibility responses, ensuring consistent visual representation in the x-pay wallet. This update;
• Ensures visual accuracy of card representation in x-pay wallets during and after token provisioning.
• Avoids confusion or misalignment caused by outdated card art.
• Empowers clients to reflect branding updates and design refreshes without friction.
• Enhances the end-user experience by aligning what users see with the latest issuer visuals.

Applicability

Enablement

No enablement required.

Technical info

When a client sends a new Card Art Ref via Token Update:
• The updated value is stored locally in real time.
• Subsequent calls to CheckEligibility return the new reference.
• No client-side changes are required aside from using the Token Update API appropriately.

PECA-770: Expanded Visa Lifecycle Support for PAN Update API (Meawallet I-TSP)

This release enhances the https://developer.paymentology.com/reference/pws_mea_cs_pan_update endpoint to support additional operationReasonCode values in alignment with Visa’s PAN Lifecycle API. The update
enables issuers to automate a broader set of Visa Account Updater (VAU) lifecycle events—such as
Contact Cardholder and Portfolio Conversion—via a single, streamlined API.

This enhancement empowers issuers with end-to-end automation for key VAU events, reducing the reliance on manual processing and support channels. It ensures that all relevant lifecycle scenarios from Visa’s API spec are accepted and properly handled, improving client experience and operational efficiency.

Applicability

Enablement

To Get Started:
• Ensure your integration is using https://developer.paymentology.com/reference/pws_mea_cs_pan_update
• Use the new operationReasonCode values as required.
• Confirm Visa PAN Lifecycle API connectivity is certified and active.

Technical info

Newly Supported operationReasonCode values are:
• Q – CONTACT_CARDHOLDER
• S – PORTFOLIO_CONVERSION
• B – VAU_CARDHOLDER_OPT_IN
• O – VAU_CARDHOLDER_OPT_OUT
Important Notes:
• These lifecycle updates apply to PANs only—tokens are not impacted.
• Issuers must meet Visa and MeaWallet certification prerequisites for full functionality.

PECA-775: IssuerProductConfigID Enhancement for Digital Skin Support

This enhancement enables the IssuerProductConfigID field in the MADA Token Update API to be stored correctly in Paymentology’s database (for CheckEligibility) and parsed through to MADA. The enriched field now carries card-artwork metadata. This enhancement ensures:
• Accurate digital card art is displayed across Apple Pay, Google Pay, and other wallets, matching the physical card design.
• Brand consistency & trust—cardholders immediately recognise their card.
• Reusable framework for additional issuers in the region to adopt Digital Skin quickly.

Applicability

Enablement

• Provide pcid in product_configuration_id during CreateCard.
• Provide pcid in both cardArtRefId and issuerProductConfigId within CardMetaData during TokenUpdate.

Note: only IssuerProductConfigId value will be stored in PTY DB for future tokenization.

Technical info

• Client supplies PCID in CreateCard ➜ PTY stores value.
• When MADA calls PTY for CheckEligibility, PTY responds with the same PCID in both cardArtRefId & issuerProductConfigId.
• If card level PCID is null, PTY falls back to productlevel mapping.
• To update PCID, client calls TokenUpdate with PCID in both fields (cardArtRefId & issuerProductConfigId) under cardMetadataInfo; PTY forwards to MADA and updates only issuerProductConfigId in DB.

AUTH-1455: Enablement of DE125 in FAST Feed via Flag

Banking.Live now supports including of DE125 in the ISO section of the FAST feed for Visa scheme. The inclusion of this data element will be controlled by a feature flag to ensure backward compatibility and controlled rollout. Including DE125 in the FAST feed enhances data transparency and allows clients to extract and
utilize this information for further analysis or processing.

Applicability

Enablement

If you wish to have this feature flag enabled, please contact your account manager or raise a ticket via https://support.paymentology.com/

Technical info

By default, there is no impact, as the feature flag will be turned off for all clients. Once the feature is enabled, clients will start receiving DE125 in the ISO section of the FAST feed.

AUTH-1468: Support for Alpha Currency Code in FAST Lite Request

FAST Lite has been enhanced to support the use of alphanumeric currency codes (e.g., "EUR", "USD") instead of numeric ISO codes (e.g., "978", "840") when posting transactions to Mambu. This change aligns with Mambu’s updated requirements, which now only accept alphanumeric currency codes in incoming requests.
This feature ensures compatibility with Mambu’s updated API standards, enabling successful transaction posting and processing through FAST Lite.

Applicability

Enablement

If you wish to have this feature enabled, please contact your account manager or raise a ticket via https://support.paymentology.com/

Technical info

• Clients using Mambu with FAST Lite will now be able to send currency codes in alpha code format.
• This change is not enabled by default to avoid impacting other FAST Lite clients.
• No action is needed for clients not using Mambu or not impacted by this change.

DEC-690: Improved Rule Logging – Only Triggered Rules Are Now Recorded

Previously, the rules engine recorded all evaluated rules - regardless of whether they triggered or not, into the database during transaction processing. This behaviour contributed to increased database bloat, unnecessary system load, and slower rule evaluation times.
With this change, only rules that are triggered are logged. This significantly reduces the volume of data written to the database, improving both system efficiency and performance.

Applicability

Enablement

No enablement required.

Technical info

When reviewing transactions in PayControl, you will now only see rules that were triggered. Rules that were evaluated but not triggered will no longer appear in the rule history view.