Release notes: Banking.Live 2.10

Visa mandate: COF and recurring transaction validation enhancements

New configurable validations have been added to validate received COF and recurring transactions. These improvements help in supporting the Visa Secure Digital Authentication Framework program for standing instruction merchant-initiated transactions. Standing instruction merchant-initiated transactions are transactions that involve standing instructions provided by the customer in the original customer-initiated transaction. They need to meet the same criteria as customer-initiated transactions to qualify for fraud dispute protection.

Client impact

By default, clients are not affected, and these transactions are processed as normal.

The introduced validation conditions to validate received COF and recurring transactions are set at client-level and/or product-level and include:

• By default, COF and Recurring transaction validation will be bypassed.
• Check the previously approved transaction for that PAN having Card Acceptor Identification Code DE42 value same as the current COF or Recurring transaction. If it does not exist, decline the transaction.
• Check the previously approved Account Verification transaction DE25 = 51 for that PAN having Card Acceptor Identification Code DE42 value the same as the current COF or Recurring transaction. If it does not exist, decline the transaction.
• Check the previously approved transaction having transaction identifier (DE62[2]) same as the current value of the Original Transaction Identifier (DE125[03].03) and the transaction should either match Merchant ID i.e. DE42 or Merchant Name i.e. DE43[1] with previous approved transaction. If it does not exist, decline the transaction.
• Check the previously approved transaction Merchant Name (DE43_1) with the current transaction Merchant Name (DE43_1). If it does not exist, decline the transaction.

Condition 1 is the default. If you need to change the validation to a different condition, you can raise a request through the Customer Support Platform.

Visa mandate (0029985): CVV2 is no longer required for Visa Secure transactions in Europe

Before PSD2 SCA, the purpose of validating CVV2 was to validate the possession of the card. However, since the release and implementation of PSD2 SCA in Europe, the additional validation of CVV2 is not required.

As of April 2024, Acquirers are no longer required to provide the CVV2 in the authorization message for transactions authenticated using Visa Secure in Europe.

❕

Due to this change in requirement, Issuers must not decline a Visa Secure transaction in Europe based solely on a missing CVV2 value.

Client impact

Visa Secure transactions in Europe will not be declined based solely on a missing CVV2 value.
You can refer to the below table for use case examples for eCommerce transactions:

Approve transactions as CAVV is valid when:

• Transaction is in EEA country
• CAVV is valid
• CVV2 is missing, invalid or valid

Approve transactions as CAVV validated by Visa when:

• In EEA country
• CAVV validated by Visa
• CVV2 is missing, invalid or valid

Decline the transaction as CVV2 was invalid or missing when:

• Not in EEA country
• CAVV valid
• CVV2 is missing or invalid

Mastercard mandate (AN8498):CVC2complaince requirements on CNP tokenized and authenticated transactions for issuers and merchants in Asia/Pacific region

As part of the mandate, Banking.Live will not decline an authorization request solely due to a lack of CVC2 data for authenticated transactions, including those originating with tokenized credentials.

This is because tokenized transactions are more secure because they contain additional security features such as the token, token expiry, and Digital Secure Remote Payment (DSRP) cryptogram.

Client impact

A domestic authorization will not be declined solely due to lack of CVC2 for authenticated transactions, including those originating with tokenized credentials.

You can refer to the below table for use case examples:

Mastercard mandate (AN7102): Introduction of Mastercard TLID

Mastercard is introducing a new Data Element (DE) 105 (Multi-Use Transaction Identification Data), sub element 001 (Transaction Link ID LID]) ) that is designed to carry a new Mastercard-generated identifier which will be used identically across the Authorization, Clearing and Single Message System platforms and all message specifications.

This transaction identifier generated by Mastercard is designed to help promote an improved and consistent linking of life cycle activity occurring after the original transaction and other related transactions.

Client impact

Clients using FAST are impacted in two ways:

1. For FAST authorization messages you can choose to receive this TLID in “DE105” in the ISO node of the FAST authorization message.
   FAST authorization message Message_Type’s impacted are:
   1. All: if you do wish to receive this TLID in the FAST authorization message, you can request this through the Customer Support Platform.
2. For FAST clearing messages you will receive this TLID in “DE105” in the ISO node of the FAST clearing message.
   FAST clearing message Message_Type’s impacted are:
   1. 1240 – First Presentments

Mada mandate: Support for Mada DS based authentication tags for SPG transactions

As part of our rollout for MADA SPG (Saudi Pay Gateway) mandate, we have implemented support for MADA DS based transactions.

MADA DS based 3DS cardholder-initiated transactions made using the physical card credentials will have additional tags in DE47 for authentication value verifications.

Client impact

Once certified, clients will receive these additional tags in the ISO node of the FAST message of these types of transactions.

Mada clients will receive additional communication from Paymentology with further details as part of the SPG Service – Mada implementation rollout.

Filter/Search for transactions using Digital Token or Device ID

PayControl users can now search for transactions by Digital Token or Device ID.

📓

TIP

A device may have multiple digital tokens linked to it, but a digital token can only be linked to one device

Client impact

Clients can choose to use this additional functionality at any stage.

You can do this by:

1. Once logged in to PayControl, navigate to the transactions screen. For example: https://uat.banking.live/paycontrol/transactions
2. In the Filter By dropdown menu, you will now find Digital Token and Device ID under the Advanced heading. Click on the method you wish to filter/search by.
3. Proceed to type in the Digital Token or Device ID you are searching for.
4. Click the search icon button.
5. The transaction screen will now populate with transactions based on your filter input.

Highlighting triggered rules in rules detail screen despite error

Rules that are triggered but not executed due to errors will still be marked as Triggered, and highlighted.

Client impact

Minor change to the Rules Detail screen on PayControl.

Now a triggered rule where an error was present will be reflected in two ways on the Rules Detail screen in PayControl:

1. Rule triggered: Err-Yes
2. The rule will be highlighted in green

You can see this screen by:

1. Once logged in to PayControl, navigate to the transactions screen. For example: https://uat.banking.live/paycontrol/transactions
2. Right click on the specific transaction and proceed to View Transaction > View Txn Details
3. On the Transaction Detail screen, click on the Rules Detail tab.