Release notes: Banking.Live 3.2

---

CLR-1013: Parsing and storage of new PDS elements for Corporate Line Item Detail Addendum Messages

Support has been added for the new PDS Elements for Corporate Line Item Detail Addendum Messages. The new fields are stored as JSON in t_set.pds_values. Elements with subfields have been added to de48_schema.yaml.

Applicability

Enablement

No enablement required.

Technical info

Below is the list of PDS elements that we have added support for; PDS 0596 (Acceptor Tax ID) PDS 0597 (Total Tax Amount) PDS 0641 (Product Code) PDS 0642 (Item Description) PDS 0645 (Item Unit of Measure) PDS 0783 (Fleet Product Code) PDS 0784 (Fleet Item Description) PDS 0786 (Fleet Item Unit of Measure)

INT-411: Support for Visa Digital Commerce Authentication Program (VDCAP) Data Elements for Domestic and Cross-Border Transactions

Visa has expanded support for the Visa Digital Commerce Authentication Program (VDCAP) indicator globally, covering both domestic and cross-border card-not-present transactions. The following existing Visa fields are used to transmit VDCAP-related information, including the authentication program and customer contact data: TLV Field 34 – Acceptance Environment Data, Dataset ID 01, Tag C0 – Authentication Program TLV Field 56 – Customer Related Data, Dataset ID 02, Tag 83 – Other Phone Number TLV Field 111 – Additional Transaction-Specific Data, Dataset ID 56, Tag 89 – Applied Special Service A parsing issue in Field 111 (Additional Transaction-Specific Data) was identified and corrected to ensure accurate interpretation of Tag 89 – Applied Special Service. This update ensures that all VDCAP-related data elements included in Visa authorization messages are correctly interpreted and processed. No other structural or functional changes were required

Applicability

Enablement

No enablement required.

PECP-950: Update PayControl password requirements to meet PCI 4.0 standards.

We have updated our password complexity requirements to further strengthen account security. If a password is used as an authentication factor, it should now meet the following minimum complexity standards: Be at least 12 characters long Contain no whitespace Include at least one uppercase letter, one lowercase letter, one number, and one special character

Applicability

Enablement

Clients will now be prompted to change their password during login only if their existing password does not meet the PCI 4.0 password complexity requirements.

Technical info

If the current password already meets the required complexity standards, clients can log in normally without seeing the Change Password screen.

AUTH-1693: Card Expiry Validation – Change from YYMMDD to YYMM (Configurable by Feature Flag)

The system previously validated card expiry dates down to the specific day (YYMMDD). However, market practice typically applies expiry validation through the end of the expiry month (YYMM). We have introduced a new feature flag, that will provide flexibility to choose your preferred validation method: Default (current behaviour): Validate using YYMMDD. New behaviour (when enabled): Validate through the entire expiry month (YYMM). This enhancement aligns expiry validation behaviour with industry standards while allowing clients to maintain their existing configuration if preferred.

Applicability

Enablement

If you wish to have this flag enabled, please raise a ticket through our customer support platform to request that the Card Expiry Validation flag be set and include the name of the flag you wish to activate in your request: Enable the flag (expiry_date_validation_with_yymm_format_only) to ensure we apply expiry validation through the end of the expiry month (YYMM), keeping cards active until the end of the expiry month instead of the day indicated, i.e. 31 December 2025 where YYMMDD = 251205 For existing behaviour no action is needed and we will validate using YYMMDD, i.e. 5 December 2025 where YYMMDD = 251205

Technical info

The name of the flag is: expiry_date_validation_with_yymm_format_only

PECR-656: QVR Enhancement

We have enhanced the QVR report generation function (ps_get_qvr_data). We have introduced a new rule to classify transactions issued in the UK but processed in EEA countries as Non-EEA. This change ensures that UK-issued transactions processed in Europe are reported accurately under the Non-EEA category, aligning QVR reporting with compliance and regulatory requirements.

Applicability

Enablement

Clients will automatically receive the updated classification in the next QVR report run, no other changes are required.

Technical info

NA.

---

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

The Set Card Status V2 function has been enhanced to allow unblocking of cards that are “dynamically blocked.” By setting the status to status_nwk = 1000, the platform now updates the record and automatically expires the dynamic block, restoring the card to active status.

Applicability

Enablement

When to use: After resolving the trigger for a temporary (dynamic) block and you want to make the card fully active again. How to invoke: Call Set Card Status V2 with status_nwk = 1000. No additional flags are required.

Technical info

NA.

PECA-837: Support new card statuses 1010 (Due Payment Block) & 1011 (KYC/AML Hold)

We are introducing two new card statuses—1010: Due Payment Block and 1011: KYC/AML/Compliance Hold. These statuses are now enforced consistently across Set Card Status (v1 & v2), Get Card APIs, tokenization flows (wallet tokens & push provisioning), 3-D Secure enrolment, and Renew/Replace flows. This update ensures clients can distinguish between payment delinquency vs. compliance holds with a more precise card status.

Applicability

Enablement

Clients can now update status to include 1010 and 1011 via SetCardStatus.

Technical info

NA.

PECR-776: Add support for MPAN and APAN

We have added MPAN and APAN Apple Pay monthly metrics to the existing report. These metrics are derived from the Mastercard DSP ID (PDS16) data element. To receive this data, clients are kindly requested to enable the DSP ID in their Mastercard configuration.

Applicability

Enablement

To receive this data, clients are kindly requested to enable the DSP ID (PDS16) in their Mastercard configuration.

Technical info

2 new metrics are added to the report Monthly MPAN spend. Monthly APAN spend.

AUTH-1707: New Decline Card Statuses for Due Payment Block

We have introduced new decline card statuses for due payment block as follow: Card Status 1010 – Blocked card (Past due statement) Reason Code: 417 – Nwk_status override: Blocked card – Past due statement Response Codes: Mastercard: 62 Visa: 62 MADA: 119 Card Status 1011 – Blocked card (Compliance hold) Reason Code: 418 – Nwk_status override: Blocked card – Compliance hold Response Codes: Mastercard: 62 Visa: 62 MADA: 119

Applicability

Enablement

Clients can now update status to include 1010 and 1011 via SetCardStatus.

Technical info

NA.