Release notes: Banking.Live 3.12

---

AUTH-2321: Introducing Age Verification Capability Dual Message and Single Message System

Support has been added for Mastercard Age Verification during authorization processing in accordance with Mastercard requirements effective 2 June 2026. The enhancement enables processing of Mastercard Data Element (DE) 118, allowing merchants and acquirers to perform near real-time age verification checks during authorization. The solution supports up to five independent age-threshold verification requests per transaction.

The implementation includes: Support for DE 118 subelement 001 (Age Verification Request), where age thresholds are provided using the Mastercard-defined format. Support for DE 118 subelement 002 (Age Verification Result), allowing issuers to return verification outcomes for each requested threshold. Support for Mastercard DE 117 (Additional Transaction Reference Data 2), which contains supplementary information related to Funding Transactions, MoneySend Payment Transactions, and Gaming Payment Transactions. Support for forwarding DE 117 and DE 118 through FAST messages when enabled.

Applicability

Enablement

Forwarding of DE 117 and DE 118 through FAST is controlled by the feature flag: enable_de117_de118_for_fast Default Value: false Clients requiring DE 117 and DE 118 data within FAST authorization messages can request feature enablement via Support.

Technical info

DE 118 – Age Verification Request Fields DE118.001.001 – DE118.001.005 Supports up to five age-verification requests per transaction. Request format: XXD XX = age threshold D = Date of Birth verification method (currently the only supported method) Response Fields DE118.002.001 – DE118.002.005 Supported response values: Processing Rules Results are returned only for request slots present in the authorization request. Only verification method D is supported. Unsupported verification methods return U. Missing cardholder date-of-birth information returns U. DE 117 – Additional Transaction Reference Data 2 Support has been added for Mastercard DE 117. This field may contain additional information related to: Funding Transactions MoneySend Payment Transactions Gaming Payment Transactions FAST Message Support When enable_de117_de118_for_fast is enabled, DE 117 and DE 118 are forwarded to clients within FAST authorization messages.

Example "DE117":"0010580010020100200812345678003006PRABIN004007POKHARA005005NEPAL", "DE118":"00102700100313D00200318D00300321D" In this example, age verification is requested for the following thresholds: 13 years 18 years 21 years using verification method D.

AUTH-2322: Revised Standards for Name Validation Support Requirements for Issuers Become Effective

Authorization processing now returns an unverified response when a valid Mastercard Name Validation request is received but issuer-side cardholder first name and/or last name data is unavailable. This update addresses a scenario where the response field could previously be omitted and ensures that a defined outcome is returned for in-scope Name Validation requests. Existing match, partial-match, and mismatch behaviour remains unchanged where comparison data is available.

Applicability

Enablement

Where Mastercard Name Validation is in use, confirm that ACCOUNT_NAME_INQUIRY_FEATURE_ENABLED is enabled for the relevant setup. Downstream validation, reconciliation, and message-handling logic should also be reviewed so U is accepted as a valid response outcome alongside the existing match-response values. No action is required where Mastercard Name Validation is not used.

Technical info

DE108 in FAST is sent as a single node, not in a sub-parsed nested JSON format. Hence, the client will receive this as a single string value

---

PECA-771: Endpoint Get Card Detail - ch_dob Date Format Correction

The ch_dob field returned in the EndpointGet Card Detail API response has been corrected to return a date-only value in yyyy-mm-dd format. Previously, the payload included an unnecessary timestamp component.

Applicability

Enablement

No client configuration is required.

Technical info

Affected field: ch_dob. Returned format changes from yyyy-mm-dd 00:00:00 to yyyy-mm-dd.

PECA-895: PaySecure Time-Based One-Time Password (TOTP) Validation

PaySecure now supports Time-Based One-Time Password (TOTP) validation for sensitive API operations. This enhancement introduces an additional security layer for protected requests by requiring a time-based verification code before selected actions can be completed. The purpose of this change is to strengthen protection around high-risk operations and reduce exposure to replay attacks or unauthorised reuse of sensitive request data. The validation is applied at the PaySecure API layer and is designed to strengthen control over sensitive card servicing actions and other higher-risk updates.

Applicability

Enablement

This feature is configured at the account level. To enable the TOTP validation, kindly contact your Technical Account Manager.

Technical info

TOTP can be supplied either in the X-Time-Based-Secret header or in the time_based_secret request field. Example: {"time_based_secret": "123456"} Supported enforcement modes: DISABLED OPTIONAL MANDATORY Protected requests submitted without a valid TOTP value may be rejected, depending on the configured mode.

PECA-1026: PayControl: Time-Based One-Time Password (TOTP) Configuration for PaySecure Validation

PayControl now includes a TOTP configuration option that allows authorised users to manage how PaySecure TOTP validation is applied. This provides a controlled way to manage enforcement settings for sensitive PaySecure operations.

Applicability

Enablement

The configuration option is available in PayControl and is permission controlled. Enablement and setup are managed through the standard support process. Where TOTP is enabled and no active key exists, a new key can be generated and sent to the configured contact email as part of the setup process.

Technical info

The client menu now supports setting the enforcement mode to Mandatory, Optional, or Disabled through the TOTP configuration flow.

PECA-1046: MADA Tokenisation TER Notification Enriched with PCID

Paymentology has enhanced the MADA “Add Card to Wallet” tokenisation flow by including the Paymentology Card Identifier (PCID) in the Token Eligibility Request (TER) notification payload sent to downstream consumers. This enhancement improves the ability to associate tokenisation events with the correct underlying card record.

Applicability

Enablement

No separate enablement is required for the cardholder journey. The change applies to the TER notification generated as part of the existing MADA tokenisation eligibility flow. Where TER notifications are consumed downstream, parsers and message handling should be ready to accept the additional PCID parameter.

Technical info

Clients integrating with the pws_mada_check_eligibility flow should ensure their systems are prepared to consume the newly added PCID parameter in TER notifications.

PECR-903: Daily Stand-In Processing Report

A new daily CSV report has been introduced to provide visibility into stand-in processing (STIP) activity. When a client's issuing host becomes unavailable or unresponsive, Paymentology activates STIP to continue authorizing transactions. This report details why STIP was triggered, how authorization decisions were made, and the outcome of each STIP transaction. In addition, the report enables the reconciliation of transactions which were processed during issuer outages.

Applicability

Enablement

The report is available for clients that require STIP reporting and can be configured via PayControl with the task name GenerateDailyStipTransactionsReport. Delivery is supported via SFTP and email.

Technical info

Sample report format: id,work_date,transaction_id,rid_auth,mtid_code,stip_trigger_reason,client_connectivity_status,stip_trigger_timestamp,stip_mode,stip_decision_reason 1,2024-04-15,266030588847018911,18911,0120,FAST_CLIENT_TIMEOUT,UNREACHABLE,2024-04-15T08:22:11Z,BALANCE_BASED,APPROVED

DEC-1459: Enhanced Parent/Sub-Client Management for Decision Engine Entities

Decision Engine now allows users at the top-level client to view and manage entities created at sub-client level. This includes management of rules, actions, tags, named lists, and transaction reports. Sub-client users can continue to view decision trees and rules inherited from parent clients. The enhancement reduces operational friction for clients managing multiple sub-clients under a parent structure. Parent-level teams can administer Decision Engine configuration centrally without losing visibility into sub-client-owned entities, while inheritance still allows sub-clients to consume parent-defined controls.

Applicability

Enablement

Available for clients operating with a parent/sub-client hierarchy and the relevant authorisation model.

Technical info

NA.

DEC-1463: Enhanced Rule Evaluation Visibility in the Decision Engine Tab

The Decision Engine transaction-evaluation view now shows the outcome of each evaluated rule directly in the Decision Engine tab. Users can see whether a rule evaluated to TRUE, FALSE, or SKIPPED, together with any actions triggered by that rule.

Applicability

Enablement

No separate enablement is required. Once available, the enhancement can be accessed directly through the Decision Engine tab by authorised users reviewing transaction evaluation details.

Technical info

NA.

DEC-1498: Refund-Aware Historical Counting for UniversalCheck3E, 3EM, and 5E

A new optional parameter, adjust_for_refunds, has been added to the following rule functions: f_UniversalCheck3E f_UniversalCheck3EM f_UniversalCheck5E This parameter controls how refund transactions are treated when calculating historical transaction counts and aggregated amounts for rule evaluations. When adjust_for_refunds=FALSE (default behaviour), refund transactions are treated like any other qualifying historical transaction and contribute positively to both the historical transaction count and aggregated amount. When adjust_for_refunds=TRUE, qualifying refund transactions are counted in reverse. As a result, matching refunds reduce the historical transaction count and aggregated amount instead of increasing them.

Applicability

Enablement

No action is required unless refund activity should offset historical totals. To use this enhancement, adjust_for_refunds must be explicitly set to TRUE in the relevant UniversalCheck function. For assistance with implementation or rule updates, please contact your Account Manager.

Technical info

The adjust_for_refunds parameter is available in: f_UniversalCheck3E f_UniversalCheck3EM f_UniversalCheck5E Behaviour: adjust_for_refunds=FALSE: qualifying refunds increase historical count and amount adjust_for_refunds=TRUE: qualifying refunds reduce historical count and amount Each historical transaction is evaluated independently. Refunds are not linked to specific original purchases. Refund reversals are only counted backwards when adjust_for_reversals=TRUE. Example: a rule requires at least 2 prior qualifying transactions and an aggregated amount of at least 70 historical activity includes Purchase 40, Purchase 35, Refund 35 with adjust_for_refunds=FALSE: count = 3, amount = 110 with adjust_for_refunds=TRUE: count = 1, amount = 40