Release notes: Banking.Live 3.10

---

CLR-1278: Requirement to Support Certain Fields in V.I.P. and BASE II

Support has been added for additional Visa clearing data fields – Submitted Merchant Country Code and IMP Qualification Indicator – within V.I.P. and BASE II for Visa Processing V2. These fields are received from incoming clearing data and made available in FAST when present, enabling clients to access additional data elements as Visa introduces them and prepare for future scheme changes.

Applicability

Enablement

This enhancement is included in Visa Processing V2 and will be available from Banking.Live 3.8. No configuration or enablement is required. Clients are encouraged to review their FAST integrations and confirm that any downstream processing, storage, or reporting logic can safely handle the presence of these additional fields, even if they are not currently used.

Technical info

The following updates have been implemented:

New Fields

• Submitted Merchant Country Code (3 characters, alphanumeric)
• IMP Qualification Indicator (1 character, alphanumeric)

Visa Source Mapping

• V.I.P.:
  • Field 34 (Tag D8) → Submitted Merchant Country Code
  • Field 111 (Tag 8A) → IMP Qualification Indicator
• BASE II:
  • TCR E Positions 116–118 → Submitted Merchant Country Code
  • TCR E Position 119 → IMP Qualification Indicator
  • TC 33 TCR 1 Position 160 → IMP Qualification Indicator

CLR-1280: Enhancing Account Level Management for Payment and Refund Transaction Processing

Paymentology now supports Account Level Management (ALM) clearing data in PDS 0275 and PDS 0276 when present in Mastercard clearing files. These values are stored and exposed through FAST legacy within the existing iso_msg DE48 payload, enabling access to additional ALM data for payment transactions globally and refund transactions in the U.S.

Applicability

Enablement

No configuration or enablement is required. Clients who want to use these values should confirm that their DE48 parsing and downstream systems can accept and process the additional data elements.

Technical info

New data elements: PDS 0275 (ALM Service Data) PDS 0276 (Fee Amounts – Additional)

Exposure in FAST: Available in iso_msg → DE48 when present in clearing data.

---

AUTH-1826: Configurable merchant-country check for Strong Customer Authentication eligibility

Paymentology now offers a configurable option to include or exclude the merchant country in SCA (Strong Customer Authentication) eligibility checks for PSD2 contactless transactions.

This enhancement allows clients to tailor how SCA limits are applied, particularly where regulatory interpretation or operational requirements differ for transactions within or outside the EEA/UK.

Applicability

Enablement

This capability is controlled through the following product setting:

• enable_merchant_country_check_for_sca_limit
  • TRUE: SCA limits apply only to transactions where the merchant country is within the configured EEA list or GBR
  • FALSE (default): Merchant country is not considered

No action is required to maintain current behaviour. Clients can enable this setting if merchant-country-based validation is required.

Technical info

• Introduces product setting: enable_merchant_country_check_for_sca_limit
• FALSE (default): All transactions contribute to SCA limits
• TRUE: Only transactions within the configured EEA list or GBR are considered
• Previous overlapping flag logic has been removed
• No integration changes are required

CLR-1257: Default new Visa settlement processing tasks to V2

Banking.Live now ensures that any newly created ProcessSettlementVisa / SettlementProcessingVisa scheduled tasks default to Visa Processing V2. This enhancement standardises settlement processing for new implementations, while maintaining flexibility for existing configurations.

Applicability

Enablement

No action is required for new implementations, as V2 is applied by default. For environments requiring a different setup, the processing version can be controlled through task configuration: VISA_FILE_PROCESSING_VERSION 2: Visa Processing V2 (default for new tasks) 1: Legacy processing

Technical info

To rollback in an environment, set task configuration with the value 2 (V2) or 1 (legacy).

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

Time-based one-time password (TOTP) validation is now available for selected sensitive PaySecure API actions. This provides clients with the option for stronger protection against account takeover and fraud. TOTP adds a second factor for sensitive operations without changing existing card or API flows for non-protected calls.

Applicability

Enablement

TOTP validation is optional and can be enabled through configuration.

• Validation states:
  • DISABLED: No TOTP validation applied
  • OPTIONAL: TOTP accepted but not required
  • MANDATORY: TOTP required for protected endpoints
• Enforcement modes:
  • Monitor: Validation results are logged only
  • Enforce: Requests without a valid TOTP are rejected

TOTP values must be provided as a 6-digit code via either: X-Time-Based-Secret header, or time_based_secret field

Clients enabling this feature should ensure their applications and user journeys can collect and submit the TOTP code where required. To enable this configuration, clients should kindly contact Support.

Technical info

The following technical updates were implemented:

• Supported states include DISABLED, OPTIONAL, and MANDATORY
• Enforcement can be configured in monitor or enforce mode
• Protected endpoints include: sc_get_cvv2, sc_get_pan, sc_get_pin, sc_set_pin, v2_sc_get_cvv2, v2_sc_get_pan, v2_sc_get_pin, v2_sc_set_pin, v2_sc_get_perso_data, v2_sc_cvv2_verify, v2_sc_generate_MDES_digitization_data, v2_sc_generate_apple_digitization_data, v2_sc_get_detailed_card_list_by_token, v2_sc_pin_unblock
• Flows which are not affected by this change: sc_pin_verify, sc_pan_to_token, v2_sc_pin_verify, v2_sc_pan_to_token, v2_sc_get_detailed_card_list, v2_sc_get_detailed_card_list_by_account, v2_sc_get_detailed_card_list_by_customer, v3_sc_pan_to_token

DEC-1235 & DEC-1236: Dynamic Action Attributes for Triggering Rule and Tree IDs

Action attributes in Decision Engine now support dynamic system-populated values for the triggering ruleId and treeId. Previously, action attributes were limited to user-defined static text key-value pairs. With this enhancement, users can configure an action attribute so that the system automatically inserts the ID of the rule or decision tree that triggered the action.

This enhancement gives clients clearer visibility into why an action was triggered, without requiring them to hardcode rule or tree IDs into the configuration. It improves traceability, simplifies downstream analysis and troubleshooting, and reduces the risk of configuration drift when rules or trees change.

Applicability

Enablement

Clients can begin using this feature by adding action attributes in Decision Engine action configuration and selecting the dynamic attribute option for either ruleId or treeId. No hardcoded ID values are required for these attributes, as the system will populate them at runtime based on the rule/tree that triggered the action.

Technical info

NA.