Release notes: Banking.Live 3.5

CLR-1077: Email Configuration Password Encryption Support

Email service configuration has been enhanced to securely support encrypted passwords. The platform now automatically decrypts encrypted email credentials when loading configuration, ensuring email services continue to operate seamlessly while aligning with existing credential security standards. This feature release ensures:

• Security: Email passwords are stored encrypted in the database, reducing exposure if the database is compromised.
• Compliance: Aligns with security best practices for sensitive credentials.
• Consistency: Uses the same encryption/decryption mechanism as database credentials for easier management.

Applicability

Enablement

Encrypt existing email passwords in the conf_psrv.email_psw column using the same encryption method used for database passwords. Verify email configuration after deployment by checking application logs for successful email service initialization. If decryption fails, check: CONFIG_DECRYPTOR_KEY is set and correct Email passwords in conf_psrv are properly encrypted Application logs for specific error messages Note: This is a backend security enhancement with no API or interface changes. No client integration work is required beyond ensuring proper environment variable configuration and encrypted password storage.

Technical info

NA.

PECR-852: Samsung Pay Monthly Report

We are introducing the Samsung Pay Monthly Regulatory Report, a standardized monthly report designed to help issuers meet Samsung’s regulatory and reporting requirements. The report provides an anonymized, settlement-based view of Samsung Pay activity, covering both transaction performance and token lifecycle metrics, without exposing any cardholder personal data (PII). In addition to regulatory compliance, the report offers valuable program-level insights into Samsung Pay usage across products, channels, and merchants.

Applicability

Enablement

The report is delivered monthly as a single XLSX file. The sample file available upon request. Initial delivery will be managed by Paymentology teams and shared via Account Managers Once validated, delivery will transition to automated SFTP No action is required from client end.

Tech

NA.

CLR-1094: Fix on pan to token exchange for garbage pans.

PAN-to-token exchange handling has been improved for settlement batches that contain garbage PANs appearing in multiple messages. When the same garbage PAN is received more than once in a settlement batch, it will now consistently map to the same garbage token, ensuring stable and predictable settlement records.

Applicability

Enablement

No enablement required.

Technical info

NA.

PECA-856: Enhanced 3DSecure Authentication Outbound API – Full VCAS Transaction Data in additionalData

This enhancement updates the existing 3DSecure outbound API integration to include the complete set of transaction fields received from VCAS in the additionalData payload. Previously, only a subset of fields was populated, limiting transaction traceability and reconciliation. With this change, all relevant VCAS transaction attributes are consistently passed through in outbound authentication requests. Providing the full VCAS transaction data enables clients to reliably correlate 3DS authentication requests with the original transactions. This improves reconciliation accuracy, strengthens fraud analysis and investigation capabilities, and reduces operational overhead caused by missing or incomplete transaction context.

Applicability

Enablement

This feature is configurable. If access to the full VCAS InitiateAction payload is required, please contact your Account Manager to have this enabled.

Technical info

Dynamically parse additionalData - fields may or may not be as part of it depending on VCAS

PECA-911: Create Card (V1 & V2) API – Return cu_id (Customer ID) in Response

As of Febuary 2026, the Create Card API echoes the customer ID (cu_id) whenever a single card is issued. This update establishes an explicit, immutable link between the newly created card and the underlying customer entity, eliminating the need for follow-up “lookup” calls and reducing metadata mismatches. Clients who utilise cu_id field for LCM of card will now be receiving it as part of the response in Create Card to ensure smoother post-issuance operations.

Applicability

Enablement

No enablement required.

Technical info

What has changed: Additional response field: cu_id (Customer ID) will be included in the Create Card response No request changes and no behavior changes to existing fields. This feature is available in UAT now, please confirm your parser accepts the new field without breaking.