Release notes: Banking.Live 2.18

AUTH-833: VISA MANDATE - Requirements to support Visa Secure Smart Attempts Service for Visa Secure Issuers

Issuers in the below listed regions that either participate or do not participate in Visa Secure will participate in the Visa Secure Smart Attempts service:

• AP (except India)
• Canada
• CEMEA (except Albania, Azerbaijan, Georgia, Kosovo, Moldova, Montenegro, North Macedonia and Ukraine)
• LAC

In the U.S. region non-participating issuers will participate in the Visa Secure Smart Attempts service.

The existing Visa Secure Attempts service responds to authentication request messages on behalf of the issuer when either the issuer does not participate in Visa Secure or the issuer participates but their access control server (ACS) is unavailable. The existing Visa Secure Attempts service provides an electronic commerce indicator (ECI) and Cardholder Authentication Verification Value (CAVV) in the authentication response to show that the merchant attempted to obtain authentication. The Visa Secure Smart Attempts service will return an ECI 05 and a CAVV that uses a new authentication method value and a new 3-D Secure (3DS) indicator value for qualifying attempts transactions.

For further information you can refer to the Visa October 2024 and January 2025 VisaNet Business Enhancements Global Technical Letter and Implementation Guide for further information.

Applicability

Enablement

Visa clients should make sure they can process the value provided below (89).

Technical info

Banking.Live will recognize Visa Secure Smart attempt transactions and skip CAVV validation result (PKS result for CAVV) for these transactions, instead checking CAVV result code in Field 44.13.

New value of 89 in Field 126.9—Usage 3, position 2 will be applicable to the following existing CAVV key indicators in Field 126.9—Usage 3, position 3, CAVV Key Indicator:

• 10 (Visa CAAV attempts/Visa-generated CAVV first key set)
• 11 (Visa CAAV attempts/Visa-generated CAVV second key set)
• 12 (Visa CAAV attempts/Visa-generated CAVV third key set)
• 13 (Visa CAAV attempts/Visa-generated CAVV fourth key set)

FASTimpact: These values will be parsed through to clients in Field 126 of the FAST message, when populated by Visa. Note: Field 126 is already a parsed through field in FAST, therefore there is no format change to FAST.

Reports impact: No impact, this field is not included in any reports.

DEFECT-1735: New decline reason codes and descriptions for SCA related transactions

This release introduces three new decline reason codes and their descriptions for Mastercard issuing clients.

Applicability

Enablement

FAST clients issuing with Mastercard will need to make sure they can process these new decline reason codes and descriptions.

Technical info

These decline reason codes and descriptions will be parsed through in the "Processor_Reason_Code" and "Processor_Descision_Desc" fields of the "SUMMARY" node of the FAST message when applicable:

• 191: SCA Contactless Limits Exceeded (sample FAST message can be found here)
  • Example: When a contactless transaction without a PIN is declined with response code 65 due to the SCA limit being exceeded, it indicates that the cumulative transaction amount or count has surpassed the threshold permitted for PIN-less transactions under Strong Customer Authentication requirements.
• 192: SCA Ecommerce Limits Exceeded
  • Example: When an eCommerce transaction is declined with response code 65 due to the SCA limit being exceeded for low value SCA exemption, it signifies that the transaction amount or cumulative count has surpassed the allowable threshold set for Low value SCA exemptiontransactions without additional authentication under Strong Customer Authentication guidelines.
• 193: Soft Decline Requires SCA (sample FAST message can be found here)
  • Example: When a transaction is declined with response code 65 due to a general SCA requirement, it indicates that additional Strong Customer Authentication is needed, as the transaction does not meet the criteria for exemption or simplified authentication.

You can find the full list of reason codes and their descriptions here.

---

PECR-288: Addition of Network Response and Description in Authorizations report

This release introduces a new version of the Authorizations report (V3.0) which includes the Network Response Code and its corresponding description.

These new columns provide you with vital insight into transaction statuses, offering a clearer distinction between the network's initial decision and Paymentology's final response. These additions help to provide greater transparency in transaction reporting and addressing reconciliation issues.

Applicability

Enablement

To enable the new version (v3.0) of the report you can raise a ticket though our Customer Support Platform or speak with your Client Executive.

The older version of the report (v2.0) will continue to be supported as it is today. There is currently no retirement date for v2.0, so there is no immediate need to upgrade to v3.0 at this stage.

Technical info

The new version (v3.0) of the Authorizations report includes:

1. Additional columns:
   1. network_response_code (Network response)
   2. network_reponse_code_description (Network response description)
2. Renaming of existing columns:
   1. response_code (v2.0) will now be paymentology_response_code (v3.0)
   2. response_code_description (v2.0) will now be paymentology_response_code_description (v3.0)

Both versions of the report specifications are available here.

CLR-467: BL STIP - Implement file duplication prevention with unique indicators

For clients utilizing Banking.Live STIP we have introduced unique indicators in the balance update file format to prevent duplicate processing, so that Banking.Live distinguishes between different instances of the same file and avoids duplicate files/records.

Applicability

Enablement

No enablement required.

This item is specific to clients using Banking.Live STIP.
For clients that do not currently use our STIP, you can speak with your Client Executive if you wish to learn more.

Technical info

• Handling duplicate files: If an individual balance update file shares a name that has previously been used by the client, the entire file will be flagged as failed during processing.
• Handling duplicate records: If a duplicate record identifier is encountered during processing of an individual balance update, the update will be flagged as a failure. This is specific to v2.0 of the balance update file. v2.0 now includes record_id.
  • Balance update file v2.0 fields: record_id, account_id, bill_ccy, act_balance, blk_balance, token
  • Record ID field format: The record ID (record_id) can range from 1 to 40 alphanumeric characters, including hyphens and underscores, which allows for the convenient use of a UUID as a unique identifier. Please note that it cannot contain spaces.

PECP-298 & PECP-332: Show the re-attempt logs of failed/timeout passive FAST message on Transaction Details screen in PayControl

For clients using Passive FAST, you will now be able to view the logs of re-attempted Passive FAST notifications on the Transaction Details screen on PayControl. Passive FAST notifications are re-attempted in the event the first Passive FAST notification failed.

Applicability

Enablement

No enablement required.

This is purely a visual update to the PayControl Transaction Details screen.

Technical info

The Transaction Details screen will now show logs of a Passive FAST re-attempt on the Logs and Timings tabs.
Note: re-attempts only occur in the event the first Passive FAST notification failed.

PECP-183: View Parent Account tab in rules screen on PayControl

In relation to DEC-148: Introduction of Parent Accounts which was released in BL2.16, we have introduced a "Parent Account Based Rules" tab to PayControl's Rules screen. This tab allows users to:

• View Parent Account rules
• Create Parent Account rules
• Link/Unlink cards to Parent Account rules

Applicability

Enablement

No enablement required.

Technical info

N.A.

CLR-495: BL STIP - Excluding outdated balance updates

Due to the nature of batch file preparation and processing, there is a risk of inadvertently updating an older balance value and overwriting a more recent one.
This release item includes system checks to prevent such occurrences during batch processing of balance updates files.

If a balance update file is prepared and sent by the client for processing, and it is discovered during processing that the balance for the particular account was recently updated by another method (e.g. API, FAST response), the batch file update will be skipped and marked as a failure.

Applicability

Enablement

No enablement required.

This item is specific to clients using Banking.Live STIP.
For clients that do not currently use our STIP services, you can speak with your Client Executive if you wish to learn more.

Technical info

When updating the balance through a batch file, Banking.Live will verify if the last updated balance on the account is newer than the balance provided in the file. If it is, the update will be skipped and the client will be notified with an appropriate error code in the FAST Administrative Message and the Feedback File.

PECP-321: Add Parent Account scope to Add New Rule screen on PayControl

In relation to DEC-148: Introduction of Parent Accounts which was released in BL2.16, we have introduced Parent Account to the "Scope" section in the "Add New Rule" screen in PayControl.

Applicability

Enablement

No enablement required.

Technical info

N.A.

PECP-323: Add new section for Parent Account rules in Rules and Limit screen on PayControl

In relation to DEC-148: Introduction of Parent Accounts which was released in BL2.16, we have introduced "Parent Account Rule" section to the "Rules and Limit" screen on PayControl. This allows users to:

• View Parent Account rules linked to the specific card.

Applicability

Enablement

No enablement required.

Technical info

N.A.

AUTH-852: Configurational bypass offline PIN check for contactless chip transaction

This item introduces a feature flag to both product level and client level to bypass offline PIN checks for contactless transactions (DE22.1 = 07) for Mastercard issuers. This means no CVM is required for contactless chip transactions if enabled.

Applicability

Enablement

To enable this feature flag please raise a request via our Customer Support Platform or speak with your Client Executive.

Technical info

A feature flag has been introduced to both product level and client level (bypass_offline_pin_check_contactless_transaction).

When this flag is enabled, offline PIN check will be skipped for contactless chip transactions.

This feature flag is disabled by default.

---

CLR-419: Presentment reversal requests received before presentment requests

Applicability

Defect condition

There was an instance where some presentment reversal requests were received by clients prior to the initial presentment request.

Investigation showed that this was due to the initial presentment and the presentment reversal being in the same settlement file sent by the network.

Defect fix

The fix released includes settlement file checks to avoid this type of behaviour (i.e. the presentment reversal is received prior to the initial presentment by the client).

It ensures the initial presentment will get transmitted to the FAST client endpoint before a presentment reversal even if the reversal presentment and initial presentment are received in the wrong order in the same network file.

EST-658: Settlement issue in Card Test Simulator related to pre-auth-incremental and completion test cases.

Applicability

Defect condition

Test cases for Mastercard pre-auth-incremental and completion settlements were failing on the Card Test Simulator.

Defect fix

Fix restores the expected behaviour of pre-auth-incremental settlements for Mastercard test cases on the Card Test Simulator.

DEC-271: Incorrect error message being returned when trying to delete a tag if it is linked to a rule

Applicability

Defect condition

Incorrect error message of "Tag does not exist" was being returned when trying to delete a tag linked to a rule.

Defect fix

Fix restores the expected behaviour when deleting a tag from a rule.

Expected behaviour: when deleting an existing tag from a rule PayControl will populate the pop-up screen with:

"Are you sure you want to delete this tag[tag name]?
Following rules will be unlinked from the tag: [rule name] [rule name]"

DEFECT-1592: pws_rules_list API slowness

Applicability

Defect condition

pws_rules_list API was taking more than 2 seconds for some users.

Defect fix

Fix released increases speed of pws_rules_list API.

DEC-272: Rules Engine - PIN entry mode checks (DE22_2) not functioning as expected

Applicability

Defect condition

Defect encountered where PIN entry mode checks (DE22_2) were not functioning as expected when being used as part of a rule.

Defect meant that a rule with the operators "=" and "IN" when used in conjunction with DE22_2 was not triggering when it should have.

Defect fix

Fix released restores the expected behaviour of this type of rule, meaning that a rule with the operators "=" and "IN" when used in conjunction with DE22_2 will trigger as expected.

NOTE: this has been released to some environments as a HOTFIX.

DEFECT-1681: ApplePay provisioning failure due to 10 max active DPANs linked to FPAN

Applicability

Defect condition

As part of the ApplePay Lab Certification, we identified a scenario where Check Card Eligibility failed due to a limit on DPAN's.

When a token notification is received with the reasonCode = DELETED_FROM_CONSUMER_APP and no tokenState, the token status was previously not updated.

Defect fix

This fix ensures that the token status is updated to DELETED in such cases and that tokens removed from user devices are accurately reflected in our system.

The system checks the token notification request for both reasonCode and tokenState - if the reasonCode is DELETED_FROM_CONSUMER_APP and tokenState is missing, the token status is updated to DELETED.

You can find more information on Tokenization Notifications here.

DEFECT-1687: SCA checks overriding Nwk status decline codes

Applicability

Defect condition

An issue was identified where some transactions were getting declined with code 1A on an inactive token.

Investigation showed these transactions were getting declined due to SCA checks and then overriding the network status decline code of 05 to 1A.

Defect fix

Fix ensures these types of transactions will not have the network status decline code of 05 overridden with 1A.

DEFECT-1713: SCA exemptions not applied for transactions

Applicability

Defect condition

It was identified that some ASI and MIT type transactions that had reference to an initial authenticated transaction in DE 48, were being declined based on SCA principles when they should have been approved as they qualified as being SCA exempt.

Defect fix

Fix resolves defect of ASI and MIT soft declines for new ASI/MIT transactions and their subsequent transactions, as well as handling subsequent transactions where the initial transaction occurred prior to this release.

Additional information:

• ASIwith SLI 21: not soft declined.
• ASIauthenticated followed byMIT: approved.

DEFECT-1780: Issue with PIN change when tok flag "SEND_PIN_CHANGE_SCRIPT" is enabled

Applicability

Defect condition

When a card has tok flag “SEND_PIN_CHANGE_SCRIPT” (bit position 2) enabled and its first transaction is a PIN change request, the PIN still shows as old PIN when calling any ‘get PIN’ related API’s even though PIN change has been successful.

Defect fix

Fix resolves this issue by excluding PIN change request from "SEND_PIN_CHANGE_SCRIPT” tok flags logic.

Now when a card has tok flag “SEND_PIN_CHANGE_SCRIPT“ (bit position 2) and its first transaction is a successful PIN change request, the new PIN shows when calling any ‘get PIN’ related API’s.