Release notes: Banking.Live 3.4

---

AUTH-1724: Enhancing Mastercard Transaction Link Identifier

Banking.Live now supports the enhanced use of Transaction Link Identifier (TLID) data carried in Data Element 105 (DE105). This update enables the storage and processing of new TLID sub-elements that allow related transactions—such as authorisations, reversals, refunds, and clearing messages—to be reliably linked across their full lifecycle.

Applicability

Enablement

No enablement required.

Technical info

Data Element: DE105 (TLV field) New supported sub-elements: Subelement 001 – Transaction Link Identifier (TLID) Stored in the database Returned in response messages Subelement 002 – Economically Related Transaction Link Identifier Stored in the database for lifecycle correlation Subelement 003 – Lifecycle TLID Validation, including: Subfield 01 – Action Indicator Subfield 02 – Customer-Provided TLID

---

PECA-838: Set Card Status V2 — “Dynamic Block” Removal with status_nwk=1000

Set Card Status V2 now supports the removal of active dynamic card blocks by setting the card network status to status_nwk=1000. When invoked, the platform automatically expires any existing dynamic block on the card, fully restoring the card to an active state once the underlying issue has been resolved.

Applicability

Enablement

Clients should use Set Card Status V2 with status_nwk=1000 to restore full card functionality after resolving the reason for the dynamic block. No additional flags or parameters are needed.

Technical info

When status_nwk=1000 is applied, the platform automatically expires any active dynamic block on the card at the time of the request. If no active dynamic block exists (or it has already expired), the request is processed successfully with no change applied. Card status update and dynamic block removal are handled atomically within the same flow, preventing partial or inconsistent card states. There are no API schema changes; request and response formats for Set Card Status V2 remain unchanged.

PECA-880: Client Led 3DS Challenge Decisioning

This feature enables Paymentology clients to take full control over the step-up decisioning logic for Visa Consumer Authentication Service (VCAS). Instead of Paymentology enforcing the pre-configured credentialType (e.g., OTP, OOB), clients will be able to decide based on their own internal rules and data whether to challenge a transaction, and how. Clients are now able to dynamically determine the method of cardholder authentication (OTP, OOB, or no challenge) per transaction Incorporate their own risk scoring and business logic into the decision-making process Approve or decline transactions directly without requiring cardholder challenge

Applicability

Enablement

New client level configuration enables client to decide cardholder challenge method. Please contact your Account Manager if you require this feature to be enabled.

Technical info

Key functionalities/capabilities introduced or improved Outbound API integration from Paymentology to client-specified endpoint Flexibility to override static credentialType settings per transaction Support for three decision actions: CHALLENGE, APPROVE, and DECLINE Expanded configurability for issuer preferences and risk policies

AUTH-1821: Improved Card Blocking for Offline PIN Try Limit Scenarios

This update improves how card status is handled when offline PIN retry limits are exceeded. Previously, in some cases where a card was unblocked after a PIN try limit was reached but the PIN counter was not reset, transactions could continue to be declined without the card being formally blocked. With this fix, if a card is unblocked without resetting the underlying PIN retry counters, the card will now be immediately blocked to ensure the card status accurately reflects its operational state.

Applicability

Enablement

This behaviour is enabled by default. Clients can control this behaviour using the product setting flag: block_cards_for_offline_pin_exceeded Disabling this flag allows cards to remain unblocked even if offline PIN retry counters have not been reset (not recommended, as PIN counters should be reset when unblocking PIN-blocked cards).

Technical info

NA.

PECA-887: Generate Time-Based Secret API – Response Format Documentation Correction

This update corrects the Developer Portal documentation for the /pws_generate_time_based_secret/ API. The existing example response incorrectly omits the Key Index portion of the secret field. The documentation is updated to reflect the actual API behaviour and valid response format returned by the platform The enhancement Ensures accurate integration guidance for clients configuring time-based secrets. Prevents misconfiguration of key index values in the database. Reduces onboarding friction and implementation errors caused by mismatched response expectations.

Applicability

Enablement

No enablement required.

Technical info

Reference Material/Links to documentation: Generate Time Based Secret. Corrected response sample "secret": "001#52364128".