Release notes: Banking.Live 2.26

DEFECT-2987: New reason code for ATC related declines

We've introduced a new reason code for ATC (Application Transaction Counter) related declines.

As reason codes are forwarded to clients in the FAST request, we have added a product flag in order to have this reason code enabled - meaning this reason code is disabled by default.

Applicability

Enablement

If you wish to have this new reason code enabled, please speak with your Client Executive or raise a request via our Customer Support Platform.

Technical info

The new reason code details:

"Processor_Reason_Code": "515", "Processor_Decision_Desc": "Decline - Invalid ATC",

You can read more on reason codes here.

PECA-625: I-TSP MW & VTS direct - Configurable Apple Pay DPAN Limit per Client

We've introduced configuration support for defining maximum DPAN's allowed per FPAN in Apple Pay provisioning flows.

The default cap is increased to 1000 for most clients—effectively removing the limitation—while specific clients (e.g.,Mada clients) retain a stricter cap of 10.

This provides value by:

• Ensuring better alignment with varying client-side token management strategies.
• Simplifying testing during integration phases.
• Minimizing provisioning disruptions in production, testing and during certification by avoiding unnecessary DPAN enforcement.
• Supporting custom enforcement policies where desired (e.g. Mada clients enforcing security limits).

Applicability

Enablement

Clients wishing to apply or change limits can raise a request via our Customer Support Platform.

Technical info

Default behaviour:

• VTS and MeaWallet integrations: DPAN cap rasised to 1000.
• Mada clients: enforced limit of 10 DPAN's remains active.

New capability:

• Limit is now configurable per integrations or client via back-end controls.
• Admins/Implementation teams may override the limit temporarily during testing.

PECA-683: Split Emboss File output for replacement and renewal cards

We’ve introduced logic to separate the Emboss File output into two distinct files. One for replacement cards and one for renewal cards.

This provides value by:

• Enabling clearer downstream processing by personalization bureaus.
• Enabling clean segregation of replacement vs. renewal cards in fulfillment systems.
• Supporting client-specific production pipelines and enhancing auditability.

Applicability

Enablement

If you wish to have this feature enabled, please reach out to your Client Executive.

Technical info

When this feature is enabled:

• If a batch includes both replacement and renewal cards, they will now be output into two separate files.
• The renewal file will receive the suffix _r before sending to the manufacturer.
• No format change to the contents of the file itself - only the splitting behaviour is affected.

Reminder:

• Card replacement: new PAN, new token, new expiry date.
• Card renewal: same PAN, same token, new expiry date.

AUTH-1196: New product flag to support three modes of TID operation

We've introduced a new product flag that allows for three modes of operation for how TID's are used and reused across transactions.

For existing clients, this product flag is disabled by default i.e. no change to existing behaviour.

Applicability

Enablement

If you wish to have this product flag enabled/choose a different mode of TID operation (as listed below), please speak with your Client Executive.

Technical info

The product flag supports three modes of operation:

• 0: For existing clients: in this mode, there is no change to existing logic i.e. the same TID will be reused if the trace ID (DE48_63) matched the original transaction.
• 1: Light mode: in this mode, we do not reuse a TID for a transaction that has already been settled or reversed, or received a decline advice. It should only be reused for payments which are still "open". Partially settled or partially reversed transactions are considered "open" in this mode.
• 2: Strict mode: in this mode, TID reuse is permitted only for payments that remain "open". Partially settled or partially reversed transactions are considered closed in this mode and a new TID will be created for a new transaction instead of reusing the original.

PECR-521: Rule evaluation report

A new Rule Evaluation report is available for clients using Banking.Live's Rules Engine.

This report assists clients in rule management and internal reporting.

Applicability

Enablement

If you are a Rules Engine user and wish to have this report enabled, please speak with your Client Executive.

Technical info

The Rule Evaluation report includes the following fields:

• authorisation_id
• transaction_id
• transaction_date
• merchant_type
• merchant_name
• merchant_id
• terminal_id
• card_acceptor_city
• card_acceptor_country
• transaction_amount
• currency
• customer_validation_response_code
• rules_validation_response_code
• fast_authorization_response_code
• decline_reason
• rule_id
• rule_triggered
• rule_description
• account_external_reference

When configured the report is sent via SFTP.