Release notes: Banking.Live 3.1

---

AUTH-1680: Changes to Response Code Processing

Visa will convert response code 57 (Transaction not permitted to cardholder) to 05 (Do not honor) in Field 39—Response Code when received from issuers in 0110 and 0210 messages. In place of response code 57, issuers should use a different response code that most accurately describes the reason for the decline, including 5C (Transaction not supported/blocked by the issuer) and 9G (Blocked by cardholder/contact cardholder). Banking.Live now supports the new response codes.

Applicability

Enablement

Please ensure your core banking systems can handle new response codes 5C and 9G.

Technical info

FAST messages will include a new response code 5C in the Processor_Reason_Code field of SUMMARY node, replacing 57.

AUTH-1673: Transaction Controls – Restriction to Cardholder-Initiated Transactions

Visa requires that transaction controls can only be applied to cardholder-initiated transactions (CITs). If a card is temporarily blocked, issuers must ensure that controls are not applied to the following types of transactions: Deferred authorization requests Incremental authorization requests Merchant-initiated transactions (MIT) or recurring transactions Mobility and transport transactions (if the cardholder has already started a journey) No-show transactions We have introduced a new feature flag to manage this behaviour. By default, the flag will be set to false to maintain the existing behaviour, and issuers should request to enable it once ready.

Applicability

Enablement

By default, the flag will be set to false to maintain the existing behaviour. Issuers who wish to enable this functionality should contact their account managers to request activatio. Kindly add to your request that you wish to have non _cit_temp_card_block_validation_bypass_enabled flag enabled.

Technical info

The feature is delivered behind a configurable feature flag (non_cit_temp_card_block_validation_bypass_enabled) Default: false → system continues current behaviour.

AUTH-1664: Mastercard Revised Standards for Acceptor Business Codes

Mastercard is adding 13 new MCCs to support new hotels, and one new MCC to support a new airline. We have added the new MCCs to database so that its recognizable on Fast request message.

Applicability

Enablement

Please ensure your system can support and be able to act on, authorization, and clearing messages that contain the new MCCs.

Technical info

NA.

---

MHC-612: Enhanced PIN Security and Weak PIN Validation

We are introducing two important updates to our PIN security system:

1. Enhanced Error Reporting: We will provide consistent error reporting in the sc_set_pin API endpoint (v1 and v2). Previously, some weak PIN scenarios returned error "There was error while setting pin. Please try again or contact Paymentology". We will in future send a more specific error message "Please use a strong PIN". All weak PIN validations will now consistently return "Please use a strong PIN".
2. Enhanced Weak PIN Rules: Additionally, weak PIN validation rules, aligned with Thales industry standards, will be introduced. These new rules expand our existing PIN security measures to ensure stronger PIN requirements across both SSM and HSM systems.

Applicability

Enablement

Verify error handling: Confirm your applications properly handle error ID 1301 responses from sc_set_pin endpoints. Review existing logic: If your system currently handles error ID 1076 for PIN-related scenarios, ensure this logic accounts for the change to 1301. Prepare for additional validations: Be aware that the expanded weak PIN rules may result in more PIN rejection scenarios. Consider implementing client-side pre-validation to help users select PINs that comply with the enhanced rule set.

Technical info

The expanded weak PIN rule set includes the following validation criteria. Any PIN violating these rules when submitted via sc_set_pin (v1 and v2) will result in error message, "Please use a strong PIN”:

1. Sequential Ascending Digits Any PIN with consecutive ascending numbers from start to end Examples: 1234, 123456
2. Sequential Descending Digits Any PIN with consecutive descending numbers from start to end Examples: 4321, 654321 3. Excessive Digit Repetition Any PIN where a single digit appears more than half the total PIN length Examples: 1111, 3303 Note: PINs like 1122 remain acceptable as no single digit exceeds the threshold

DEC-894: Wallet Provider Support for X-Pay Rule

The X-Pay rule now includes support for wallet provider identification, allowing enhanced precision when evaluating previous wallet-based transactions. Rule Logic The rule operates in two phases: Phase 1: If current transaction is Foreign XPay (Outside Iceland) AND The card has had an MDES tokenization request in last 24 hours - proceed to phase 2. Phase 2: If the transacting card has domestic XPay (Inside Iceland) in last 2 months, rule does not trigger. If the transacting card has NO domestic XPay (Inside Iceland) in last 2 months, rule will trigger.

Applicability

Enablement

NA.

Technical info

Enhancement The wallet provider value is now available within the rule. This enhancement enables Phase 2 to consider only previous transactions conducted on the same wallet as the current transaction (e.g., Apple Pay, Google Pay, Samsung Pay).

AUTH-1740: Money Send (Payment transaction) to skip EMV validation

For a payment transaction in Mastercard, EMV validation was applied leading it to be declined based on invalid AC type received. While this check is valid for normal EMV transactions, this needed to be skipped for payment-based transactions. We have applied a fix to ensure that the money send transactions are not declined based on cypto or emv validations.

Applicability

Enablement

Paymentology will automatically enable this change

Technical info

NA.