PECA-797: Introduction of Secure API for Fetching Personalisation Data

Paymentology will be deprecating Personalisation Data API (https://developer.paymentology.com/reference/pws_perso_data). A new, secure replacement API will be introduced under the PaySecure API suite, aligned with our standard security and access protocols.

This update ensures that sensitive card personalisation data is handled securely and in accordance with best practices, reducing the risk of data exposure or misuse

Applicability

Enablement

Migration Required: Any planned or ongoing integrations using the deprecated API must be reconfigured to use the new API endpoint once released.

Technical Info

The existing /pws_perso_data / API is deprecated and should no longer be used for any integration.

A new, secure API /sc/v2/sc_get_perso_data/ will be made available under the PaySecure service umbrella for fetching personalisation data.

The new API will follow the same secure access model as other PaySecure APIs, including token-based authentication and stricter access controls.

Header details

Generate 32 bytes random value and encode as base64 string termed as the session key.

The base64 encoded string should be encrypted with rsa public key.

The encrypted value will be passed in the header request under Session-Id

Later, this session key will be used to encrypt the sensitive data in the response

PECR-718: Quarterly Mastercard Report (QMR): Restricted Accounts/Cards Now Counted as “Open”

We have updated how the “accounts/cards at the beginning of quarter” metric are calculated in the Quarterly Mastercard Report. Previously, restricted accounts/cards used to be considered as “Temporarily blocked”. From this quarter (Q3 2025) onward, restricted accounts/cards are now considered under “Open” for a more precise reporting.

This change ensures precise reporting of the Quarterly Mastercard Report values uploaded to Mastercard’s portal.

Applicability

Enablement

No enablement required

Technical Info

NA.

PECR-760: Quarterly Visa Report (QVR): Total Number of Cards Metric Now Excludes Terminated Cards

We have refined how the “total number of cards” metric is calculated in the Quarterly Visa Report. In the past, the count excluded only expired cards. From this quarter (Q3 2025) onward, the count will exclude both expired and terminated cards for a more precise reporting.

This change ensures precise reporting of the quarterly visa report values uploaded to the portal.

Applicability

Enablement

No enablement required.

Technical Info

NA.

DEC-924: Non-Triggered Rules Restored on the Transaction Detail Screen

We improved rule processing speed by changing how non-triggered rules were logged. While this delivered significant performance benefits, it meant that non-triggered rules were no longer shown in PayControl. After receiving feedback that visibility of these rules is important, we have updated the UI to once again display non-triggered rules. This update sources them in a new way, ensuring you have the information needed while the performance improvements remain in place.

Applicability

Enablement

No enablement required.

Technical Info

Previous functionality has been restored.

PECP-777: PayControl API Documentation Upgrade for OpenAPI 3.0.0 Compatibility

The PayControl API documentation page has been updated to support and correctly render OpenAPI 3.0.0 specifications. This change was required following the upgrade to Java 21 and Apache Camel 4.10, which replaced the deprecated camel-swagger-java module with camel-openapi-java. The PayAPI endpoint now generates OpenAPI 3.0.0 JSON, and PayControl has been adapted to display this documentation format properly.

This update ensures that clients and integrators have access to accurate, up-to-date API documentation in the industry-standard OpenAPI 3.0.0 format. It improves developer experience, reduces confusion, and supports ongoing integration and compliance needs.

Applicability

Enablement

NA.

Technical Info

The API documentation page in PayControl now displays OpenAPI 3.0.0 specifications, replacing the previous Swagger 2.0 format.

PECA-822: PayApi, SecureAPI v1 and v2: misleading generic error message if PKS responds with 'weak pin detected'

This update improves error handling by ensuring that specific errors (for example, weak PINs) are now shown clearly instead of being replaced with generic messages. This gives more accurate information and makes issues easier to understand and resolve.

Applicability

Enablement

NA.

Technical Info

By using the specified endpoints for setting the PIN, we previously returned an invalid generic error ID along with the generic description. With this change, the proper error ID is now returned for all weak PIN scenarios.

All weak PIN scenarios in sc_set_pin (v1 and v2) will now consistently return error “Please use a strong pin” (Error ID 1301).

CLR-1005: Improved Handling of Dispute Re-Presentments for Internal Ledger Clients

To prevent negative account balances during dispute cycles, we have enhanced how second presentments (re-presentments) are processed for clients using internal ledger configurations.

For dispute-related re-presentments the system now logs the re-presentment without posting a deduction, ensuring account balances remain unaffected.

Applicability

Enablement

NA.

Technical Info

NA.

PECA-765: Track Format Updated to support for 8-Digit BIN

This release ensures that card data generated via the GenerateManufacturerCard job for client’s with 8 digit BIN adheres to the track formats defined for their 8-digit BIN. The system will now validate and enforce the specified Track 1 and Track 2 formats during card manufacturing.

Applicability

Enablement

Clients need to review their embossing/personalization workflows to confirm alignment with the enforced format.

Technical Info

Before: Cards were generated in a different format than defined (e.g., unexpected output in Track 1, Track 2, and Chip Track 2).

Now: The system enforces the following track structure for all cards:

Track 1 = KPPPPZZCCCZZZZZZ

Track 2 = KPPPPZZZZZCCC

Any deviations are prevented at the generation stage, ensuring correct embossing and personalization file output.

DEFECT-3838: Use dynamic mapping of ISO8583 standard response code (DE39) for MAMBU error reason code

In the existing version, Mambu error reason codes were mapped hardcoded and only limited to two ISO 8583 standard response code.

Current mapping details

With this feature we can configure and map to suitable DE39 that corresponds with the MAMBU error reason code.

Applicability

Enablement

When using the new feature for dynamic response code mapping, a new DE39 (response code) will be included in the FAST message. Please note that this response code must be agreed with you in advance.

If no new mapping is configured, there will be no impact. The system will continue to use the existing response code mapping by default

Technical Info

NA.

AUTH-1630: New Setting to Bypass Track Data Validation for Mada Tokenized Transactions

We have added product setting/flag v6013_SKIP_TRACK_DATA_ORIGINAL_TOKENIZED to bypass track data validation for subsequent MADA tokenized transaction when its original/referring transaction is a tokenized one. This ensures compliance with updated MADA 6.0.13 version and corrects the error of rejecting a transaction.

Applicability

Enablement

The flag is disabled by default. To enable please set to TRUE for the bypass to occur when a transaction meets the criteria.

Technical Info

NA.

PECR-193: Visa Account Updater (VAU) Status Code Enhancement: Introduction of Status Codes 1007 and 1009

We have enhanced the way closed card statuses are reported for clients enrolled for Visa Account Updater (VAU). Cards flagged with status codes 1009 are now explicitly marked as closed in the daily files sent to Visa.

This update ensures that merchants can no longer attempt payments using those PANs, helping to prevent fraud and reduce declines.

Applicability

Enablement

No enablement required

Technical Info

NA.

CLR-897: Support new message reason codes for Fee Collections

Mastercard has introduced two new message reason codes to better identify installment-related fees exchanged between acquirers and issuers:

7680 – Installments: Merchant fee for single purchase

7681 – Installments: Merchant fee for aggregated purchases

These codes will be carried in DE 25 (Message Reason Code) within Fee Collection / 1740-700 messages.

We have enhanced Banking.Live to accept, process, and store these new codes when received in T112 1740 fee collection messages, ensuring full support for Mastercard’s updated requirements.

Applicability

Enablement

Please ensure your system can process these new message reason codes for installment-related fees.

Technical Info

Fee Collection (Customer-generated)/1740-700

PECA-772: Create Card API – Return cu_id (Customer ID) in Response

The Create Card API now 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

To get started & Deprecation notice

1. Enable the flag – Contact your Relationship Manager to turn on.
2. Validate in UAT – Confirm your parser accepts the new field without breaking.
3. Deprecation notice – The flag will be permanently removed on 28 Jan 2026 (± a week), after which cu_id will always be returned. Ensure production readiness before this date.

Technical Info

A temporary configuration flag lets early adopters receive the new field while existing clients can opt out. The flag will be removed six (6) months after production launch, at which point all clients must consume the updated schema.

AUTH-1429: Mastercard Mandate: Introducing Decline Response Code Values

Mastercard is introducing two new response codes in DE39 to improve clarity on decline reasons:
• 46 – Account is closed
• 72 – Account is not activated
In line with Mastercard Mandate GLB 10401.2 (Introducing Decline Response Code Values), we have updated our response logic on Banking.Live to return these codes in 0110 and 0210 messages based on internal account status. Specifically:
• If the account status is 0 (Pre-live Inactive), the system will respond with 72
• If the account status is 3 (Closed), the system will respond with 46
• For all other non-authorized statuses, the fallback response code 57 will be used

This change aligns with Mastercard’s latest messaging guidelines and enhances the precision of our issuer responses. Cardholders and merchants will now receive more specific decline reasons instead of the general- purpose code 57. Mastercard will receive 46 or 72 when applicable, helping reduce confusion and support inquiries.

For full details, you can refer to Mastercard’s Mandate bulletin GLB 10401.2

Applicability

Enablement

No enablement required.

Technical info

NA.

PECA-683: Split Emboss File Output for normal renewal/replacements vs early renewal/replacement Cards

We have introduced a logic to separate the Emboss File output into two distinct files—one for Replacement cards and one for Renewal cards. Banking.Live now checks both the renewal_reason value and the product level feature flag before output is generated.
This change enables clearer downstream processing by personalization bureaus and supports operational alignment for clients who manage these card types through different production and SLA streams.

Applicability

Enablement

If you wish to have this product flag enabled, please contact your account manager.

Technical info

When the feature flag is enabled:
• If a batch includes both normal renewal / replacement and early renewal / replacement cards, two separate Emboss Files are produced.
• The early renewal file receives the suffix _r before being sent to the manufacturer.
• No change to the internal record format—only the file splitting behavior is affected.

PECA-728: MADA: Synchronize Card Art Ref stored locally when updating via Token Update

This update ensures that any new Card Art Reference sent by the client via the Token Update API is now automatically synchronized with our local database. This eliminates discrepancies between the card art stored by MADA and the one returned in CheckEligibility responses, ensuring consistent visual representation in the x-pay wallet. This update;
• Ensures visual accuracy of card representation in x-pay wallets during and after token provisioning.
• Avoids confusion or misalignment caused by outdated card art.
• Empowers clients to reflect branding updates and design refreshes without friction.
• Enhances the end-user experience by aligning what users see with the latest issuer visuals.

Applicability

Enablement

No enablement required.

Technical info

When a client sends a new Card Art Ref via Token Update:
• The updated value is stored locally in real time.
• Subsequent calls to CheckEligibility return the new reference.
• No client-side changes are required aside from using the Token Update API appropriately.

PECA-770: Expanded Visa Lifecycle Support for PAN Update API (Meawallet I-TSP)

This release enhances the https://developer.paymentology.com/reference/pws_mea_cs_pan_update endpoint to support additional operationReasonCode values in alignment with Visa’s PAN Lifecycle API. The update
enables issuers to automate a broader set of Visa Account Updater (VAU) lifecycle events—such as
Contact Cardholder and Portfolio Conversion—via a single, streamlined API.

This enhancement empowers issuers with end-to-end automation for key VAU events, reducing the reliance on manual processing and support channels. It ensures that all relevant lifecycle scenarios from Visa’s API spec are accepted and properly handled, improving client experience and operational efficiency.

Applicability

Enablement

To Get Started:
• Ensure your integration is using https://developer.paymentology.com/reference/pws_mea_cs_pan_update
• Use the new operationReasonCode values as required.
• Confirm Visa PAN Lifecycle API connectivity is certified and active.

Technical info

Newly Supported operationReasonCode values are:
• Q – CONTACT_CARDHOLDER
• S – PORTFOLIO_CONVERSION
• B – VAU_CARDHOLDER_OPT_IN
• O – VAU_CARDHOLDER_OPT_OUT
Important Notes:
• These lifecycle updates apply to PANs only—tokens are not impacted.
• Issuers must meet Visa and MeaWallet certification prerequisites for full functionality.

PECA-775: IssuerProductConfigID Enhancement for Digital Skin Support

This enhancement enables the IssuerProductConfigID field in the MADA Token Update API to be stored correctly in Paymentology’s database (for CheckEligibility) and parsed through to MADA. The enriched field now carries card-artwork metadata. This enhancement ensures:
• Accurate digital card art is displayed across Apple Pay, Google Pay, and other wallets, matching the physical card design.
• Brand consistency & trust—cardholders immediately recognise their card.
• Reusable framework for additional issuers in the region to adopt Digital Skin quickly.

Applicability

Enablement

• Provide pcid in product_configuration_id during CreateCard.
• Provide pcid in both cardArtRefId and issuerProductConfigId within CardMetaData during TokenUpdate.

Note: only IssuerProductConfigId value will be stored in PTY DB for future tokenization.

Technical info

• Client supplies PCID in CreateCard ➜ PTY stores value.
• When MADA calls PTY for CheckEligibility, PTY responds with the same PCID in both cardArtRefId & issuerProductConfigId.
• If card level PCID is null, PTY falls back to productlevel mapping.
• To update PCID, client calls TokenUpdate with PCID in both fields (cardArtRefId & issuerProductConfigId) under cardMetadataInfo; PTY forwards to MADA and updates only issuerProductConfigId in DB.

AUTH-1455: Enablement of DE125 in FAST Feed via Flag

Banking.Live now supports including of DE125 in the ISO section of the FAST feed for Visa scheme. The inclusion of this data element will be controlled by a feature flag to ensure backward compatibility and controlled rollout. Including DE125 in the FAST feed enhances data transparency and allows clients to extract and
utilize this information for further analysis or processing.

Applicability

Enablement

If you wish to have this feature flag enabled, please contact your account manager or raise a ticket via https://support.paymentology.com/

Technical info

By default, there is no impact, as the feature flag will be turned off for all clients. Once the feature is enabled, clients will start receiving DE125 in the ISO section of the FAST feed.

AUTH-1468: Support for Alpha Currency Code in FAST Lite Request

FAST Lite has been enhanced to support the use of alphanumeric currency codes (e.g., "EUR", "USD") instead of numeric ISO codes (e.g., "978", "840") when posting transactions to Mambu. This change aligns with Mambu’s updated requirements, which now only accept alphanumeric currency codes in incoming requests.
This feature ensures compatibility with Mambu’s updated API standards, enabling successful transaction posting and processing through FAST Lite.

Applicability

Enablement

If you wish to have this feature enabled, please contact your account manager or raise a ticket via https://support.paymentology.com/

Technical info

• Clients using Mambu with FAST Lite will now be able to send currency codes in alpha code format.
• This change is not enabled by default to avoid impacting other FAST Lite clients.
• No action is needed for clients not using Mambu or not impacted by this change.

DEC-690: Improved Rule Logging – Only Triggered Rules Are Now Recorded

Previously, the rules engine recorded all evaluated rules - regardless of whether they triggered or not, into the database during transaction processing. This behaviour contributed to increased database bloat, unnecessary system load, and slower rule evaluation times.
With this change, only rules that are triggered are logged. This significantly reduces the volume of data written to the database, improving both system efficiency and performance.

Applicability

Enablement

No enablement required.

Technical info

When reviewing transactions in PayControl, you will now only see rules that were triggered. Rules that were evaluated but not triggered will no longer appear in the rule history view.

Auth-1214: Mastercard Mandate: GLB 10432.2 Enhancing Send Data Fields and Name Validation Request (Update)

In line with Mastercard Mandate GLB 10432.2 (Enhancing Send Data Fields and Name Validation Request (Update)), Banking.Live will support validation of cardholder's name during an Account Status Inquiry (ASI) request. The name provided by the registered user can be verified against the name associated with the card at the issuer.

For full details you can refer to Mastercard’s mandate bulletin GLB 10432.2

Applicability

Enablement

No enablement required

Technical info

Banking.Live will support;

Full middle name in DE 108 (Additional Transaction Reference Data) subelement 01 (Receiver/Recipient Data), subfield 02 (Receiver/Recipient Middle Name) and DE 108 (Additional Transaction Reference Data) subelement 02 (Sender Data), subfield 02 (Sender Middle Name)

New value of 0 (Normal request [not for Validation request]) and 1 (Validation request) in repurposed DE 61 (Point-of Service [POS] Data), subfield 9 (POS Transaction Status – Extended)

Auth-1210: Mastercard Mandate: Revised Standards for Acceptor Business Codes (MCCs)

In line with Mastercard Mandate GLB 10318.1 (Revised Standards for Acceptor Business Codes (MCCs)), Banking.Live now supports updated MCC description of AIRMALTA to KM Malta Airlines.

For full details you can refer to Mastercard’s mandate bulletin GLB 10318.1

Applicability

Enablement

No enablement required

Technical info

Banking.Live now supports the updated name of MCC 3028 from Air Malta: AIRMALTA to KM Malta Airlines: KMMA

DEC-379: Additional logging to the Rules Engine Timing log UI when using Check Merchant Activity rule

We have provided a flag which enables additional logging to the UI when the Check Merchant Activity rule is triggered. Currently when the Check Merchant Activity rule triggers an action - only the current transaction data is available. With the additional logging enabled, current transaction and the previous transactions which led to the rule being triggered will be available.

Applicability

Enablement

Please reach out to our fraud team if you would like to enable additional logging to the UI for the Check Merchant Activity rule.

Technical info

If the flag is enabled for the Check Merchant Activity rule and it is triggered - you will see the related transactions in the Rules Engine Timing Log screen.

PECA-742: Card Status Notification added new status: Dynamic Blocking

We have extended our card-status notification framework to cover dynamic block action. Whenever a card’s status_nwk field is changed to 1034 dymanic_block (for example, during a fraud-related dynamic block), Card Status Notification now dispatches a message to the client in real time.

This ensures clients are immediately aware whenever a dynamic block happens on any card, ensuring client systems stay synchronized, allowing support teams to respond without delay.

Applicability

Enablement

No enablement required.

Technical info

Notification payloads will reuse the existing FAST CSU schema.

Expect additional CSU notifications each time you invoke (or our rules engine triggers) a dynamic block/unblock.

PECA-764: Standardized ENABLED State for APATA Card Enrollment

We have updated the APATA card enrollment logic to always send the enrollment state as ENABLED. This change addresses prior inconsistencies that led to confusion during card replacement flows when DISABLED was incorrectly used.

This change ensures a more reliable and predictable 3DS enrollment experience during card replacements. By consistently using ENABLED, we eliminate ambiguity for clients who do not differentiate based on APATA’s internal state but rely on enrollment being active.

Applicability

Enablement

All future APATA enrollment requests will use the ENABLED state by default.

Technical info

Clients will now receive a consistent ENABLED state during all APATA card enrollments, including replacements. This removes the need to interpret or handle different state values. Functionally, cardholders will experience uninterrupted 3DS enrollment for replacement cards.

AUTH-1213: Configurable Rules Engine Invocation for Tokenization Provisioning Messages

We have introduced a new product-level configuration to control whether Tokenization Provisioning and Token Lifecycle Transaction (TA, TE, TC, AC, TV) messages should be sent to the Rules Engine.

This configuration will allow finer control over Tokenization provisioning messages through Rules Engine.

Applicability

Enablement

 A new field has been added to the Products table. From UI, it’s available under Rules Engine toggle flag.

Technical info

The default behavior is to allow these messages to be sent to the Rules Engine, maintaining current functionality.

AUTH-1127: VISA MANDATE: Visa click to pay with FIDO authentication

In line with Visa Mandate AI13856 (Notice to Europe Issuers of Visa Click to Pay with FIDO Authentication), Banking.Live will allow transactions to be approved if FIDO (Fast Identity Online Authentication) was performed.

For full details you can refer to Visa’s Mandate bulletins AI13856 and AI13104.

Applicability

Enablement

No enablement required.

Technical info

Banking.Live will handle these types of transactions and consider it as FIDO authenticated, when the
following values are present:

• 123 DSID 68 Tag 83 = 42 and ECI in (05,06)

Therefore, when these values are present Banking.Live will bypass the requirement for CVV2 to be present or 3DSecure authentication to be performed as FIDO authentication was performed.

AUTH-1146: VISA MANDATE: Changes to authorization response codes

In line with Visa Mandate TL 042025 2.11 (Changes to Authorization Response Codes (Version 2.0)),
Banking.Live now supports new response codes 5C and 9G.

For Visa clients, mapping between some reason codes and response codes will be different.

For full details you can refer to Visa’s Mandate bulletin TL 042025 2.11.

Applicability

Enablement

Please make sure the new Visa response codes, and their mapping with reason codes, is supported by your system.

Technical info

For CNP transactions, the following reason codes will be mapped to different response codes compared to previously:

• CNP Reason Code 400 would be mapped to RC 5C
• Non-CNP Reason Code 400 would be mapped to RC 12
• CNP Reason Code 414 would be mapped to RC 9G
• Non-CNP Reason Code 414 would be mapped to RC 12

AUTH-1256: VISA MANDATE: Visa data only program

In line with Visa Mandate AI 14552 (Visa Secure Issuers Will Be Auto-Enabled for the Visa Data Only Program), Banking.Live now supports the bypassing of CAVV validation for Visa Data Share Only Program transactions via the enablement of a product flag.

For full details you can refer to Visa’s Mandate bulletin AI 14552.

Applicability

Enablement

If you wish to have this product flag enabled, please contact your Client Executive or raise a request via our Customer Support Platform.

Technical info

When the visa_data_share_only_cavv_bypassed product flag is enabled, Banking.Live will bypass
CAVV validation for Visa Data Share Only Program. Banking.Live identifies these types of transactions when the following values are present:

• Field 126.9, position 1 = 03 and CAVV 44.13 = B and ECI 60.8 = 07

AUTH-1145: Issuer On-Behalf Services (OBS) 52 check for CVV validation

This enhancement improves transaction efficiency by reducing unnecessary CVV checks when Mastercard’s pre-validation service (OBS 52) confirms it’s already valid.

Applicability

Enablement

No enablement required.

Technical info

For tokenized transactions, if Banking.Live receives OBS 52 (Mastercard Digital Enablement Service
CVC 3 Pre-Validation) as valid and the PAN auto-entry via a magnetic stripe or contactless magnetic
stripe, CVV validation will be skipped based on the OBS result.

AUTH-1170: Logic update: reset update offline PIN counter

We have updated the logic of the offline PIN and unblock script to align with the same behaviour of
online PIN counter resets.

Prior to this release:

• offline PIN block issuer script is only transmitted to the chip when the offline PIN counter is less than 1, e.g. 0.
• for online PIN transactions, the PIN counter is consistently reset each time a PIN is validated.

After this release:

• offline PIN block issuer script is transmitted to the chip and the PIN counter is reset in every EMV contact transaction with a valid online PIN.
• no change to online PIN counter and reset.

To make this change easier for clients, we have introduced this under a new product flag “max_pin_counter”. The default value of this product flag has a max offline PIN counter of 3.

Applicability

Enablement

If you wish to have this product flag enabled, please contact your Client Executive or raise a ticket via our Customer Support Platform.

Technical info

NA.

DEFECT-3000: Addition of product flag: SCA exemption

We’ve introduced a new product flag relating to SCA transactions.

This product flag has been created to solve for SCA exemption transaction scenarios where the recurring indicator field is not present in DE48 SE 22 SF1.

Note: this product flag is disabled as default.

Applicability

Enablement

If you wish to have this product flag enabled, please contact your Client Executive or raise a ticket via our Customer Support Platform.

Technical info

Behaviour when“allow_trace_link_for_recurring” product flag is disabled:

• when the recurring indicator field DE48 SE 22 SF 1, which should contain the value 03, was missing from the transaction – the trace ID lookup was not being triggered – resulting in an SCA decline. However, the recurring indicator in DE61 SE 4 was still present.

Behaviour when“allow_trace_link_for_recurring” product flag enabled:

• trace ID lookup will be executed based on the presence of recurring indicator field DE48 SE 22 SF 1 and/or presence of recurring indicator in DE61 SE 4.

DEFECT-2987: New reason code for ATC related declines

We've introduced a new reason code for ATC (Application Transaction Counter) related declines.

As reason codes are forwarded to clients in the FAST request, we have added a product flag in order to have this reason code enabled - meaning this reason code is disabled by default.

Applicability

Enablement

If you wish to have this new reason code enabled, please speak with your Client Executive or raise a request via our Customer Support Platform.

Technical info

The new reason code details:

"Processor_Reason_Code": "515", "Processor_Decision_Desc": "Decline - Invalid ATC",

You can read more on reason codes here.

PECA-625: I-TSP MW & VTS direct - Configurable Apple Pay DPAN Limit per Client

We've introduced configuration support for defining maximum DPAN's allowed per FPAN in Apple Pay provisioning flows.

The default cap is increased to 1000 for most clients—effectively removing the limitation—while specific clients (e.g.,Mada clients) retain a stricter cap of 10.

This provides value by:

• Ensuring better alignment with varying client-side token management strategies.
• Simplifying testing during integration phases.
• Minimizing provisioning disruptions in production, testing and during certification by avoiding unnecessary DPAN enforcement.
• Supporting custom enforcement policies where desired (e.g. Mada clients enforcing security limits).

Applicability

Enablement

Clients wishing to apply or change limits can raise a request via our Customer Support Platform.

Technical info

Default behaviour:

• VTS and MeaWallet integrations: DPAN cap rasised to 1000.
• Mada clients: enforced limit of 10 DPAN's remains active.

New capability:

• Limit is now configurable per integrations or client via back-end controls.
• Admins/Implementation teams may override the limit temporarily during testing.

PECA-683: Split Emboss File output for replacement and renewal cards

We’ve introduced logic to separate the Emboss File output into two distinct files. One for replacement cards and one for renewal cards.

This provides value by:

• Enabling clearer downstream processing by personalization bureaus.
• Enabling clean segregation of replacement vs. renewal cards in fulfillment systems.
• Supporting client-specific production pipelines and enhancing auditability.

Applicability

Enablement

If you wish to have this feature enabled, please reach out to your Client Executive.

Technical info

When this feature is enabled:

• If a batch includes both replacement and renewal cards, they will now be output into two separate files.
• The renewal file will receive the suffix _r before sending to the manufacturer.
• No format change to the contents of the file itself - only the splitting behaviour is affected.

Reminder:

• Card replacement: new PAN, new token, new expiry date.
• Card renewal: same PAN, same token, new expiry date.

AUTH-1196: New product flag to support three modes of TID operation

We've introduced a new product flag that allows for three modes of operation for how TID's are used and reused across transactions.

For existing clients, this product flag is disabled by default i.e. no change to existing behaviour.

Applicability

Enablement

If you wish to have this product flag enabled/choose a different mode of TID operation (as listed below), please speak with your Client Executive.

Technical info

The product flag supports three modes of operation:

• 0: For existing clients: in this mode, there is no change to existing logic i.e. the same TID will be reused if the trace ID (DE48_63) matched the original transaction.
• 1: Light mode: in this mode, we do not reuse a TID for a transaction that has already been settled or reversed, or received a decline advice. It should only be reused for payments which are still "open". Partially settled or partially reversed transactions are considered "open" in this mode.
• 2: Strict mode: in this mode, TID reuse is permitted only for payments that remain "open". Partially settled or partially reversed transactions are considered closed in this mode and a new TID will be created for a new transaction instead of reusing the original.

PECR-521: Rule evaluation report

A new Rule Evaluation report is available for clients using Banking.Live's Rules Engine.

This report assists clients in rule management and internal reporting.

Applicability

Enablement

If you are a Rules Engine user and wish to have this report enabled, please speak with your Client Executive.

Technical info

The Rule Evaluation report includes the following fields:

• authorisation_id
• transaction_id
• transaction_date
• merchant_type
• merchant_name
• merchant_id
• terminal_id
• card_acceptor_city
• card_acceptor_country
• transaction_amount
• currency
• customer_validation_response_code
• rules_validation_response_code
• fast_authorization_response_code
• decline_reason
• rule_id
• rule_triggered
• rule_description
• account_external_reference

When configured the report is sent via SFTP.

MAND-368 & AUTH-1150: Assigning new leading indicators to AAV for Smart Authentication Direct Services

In line with Mastercard Mandate GLB 10437.2 (Assigning New Leading Indicators to the Accountholder Authentication Value (AAV) for Smart Authentication Direct Services).

Banking.Live now provides support for:

• Supporting AAV leading indicator kJ for successfully authenticated Smart Authentication Direct transactions with Security Level Indicator (SLI) 212.
• The kJ leading indicator will replace the current kC leading indicator shared between Smart Authentication Direct and Smart Authentication Stand-In. Smart Authentication Stand-In low-risk will solely generate the kC leading indicator.
• Supporting AAV leading indicator kU for successfully authenticated SADAE (Smart Authentication Direct Acquirer Exemption) transactions with SLI 216.

This is applicable to Issuers participating in the Mastercard Identity Check program that are enrolled or have opted-in to SADAE.

Applicability

Enablement

No enablement required.

If you require further information you can refer to the Mastercard Mandate bulletin GLB 10437.2 or reach out to your Client Executive.

Technical info

AAV leading indicator fields/values:

Authorization:

• kJ in DE 48, subelement 43, positions 1 and 2 for successfully authenticated Smart Authentication Direct transactions with SLI 212.
• kU in DE 48, subelement 43, positions 1 and 2 for successfully authenticated SADAE transactions with SLI 216.
• The AAV will not be sent in Authorization Request/0100 messages to the Issuer when a transaction is downgraded.

Clearing:

• kJ in PDS 0185 for successfully authenticated Smart Authentication Direct transactions with SLI 212.
• kU in PDS 0185 for successfully authenticated SADAE transactions with SLI 216.

PECP-555: View transaction detail by double-clicking on the transaction row

You can now double-click on a transaction on PayControl to open the transaction detail pop-up screen. Previously, you could only open this pop-up screen via right-click.

Applicability

PECA-681: Enable sending of failed TAR notifications

For clients using Paymentology tokenization notification services, you can now opt-in to receive Tokenization Authorization Request (TAR) notifications where the AuthorizeService has failed.

These notifications will include detailed risk & device or error information for any AuthorizeService failures such as those that fail due to the deviceScore = 01.

You can read more on tokenization notifications here.

Applicability

Enablement

If you are a Paymentology tokenization client and wish to receive failed TAR notifications, please speak with your Client Executive.

DEFECT-1319: Addition of new product flag relating to ASI transactions

We've introduced the product flag “enable_asi_constraint_for_tid”.

When this product flag is enabled the Transaction Identifier (TID) will be unlinked (creating a new TID) if a pre-auth transaction attempts to link to an original transaction (by trace ID) that is an Account Status Inquiry (ASI) transaction.

Please note: this product flag is disabled by default for existing clients.

Applicability

Enablement

No enablement required.

If you wish to have this product flag enabled, please reach out to your Client Executive.

AUTH-1137: Update of currency code from ANG to XCG for Curacao and Sint Maarten

The currency code for Curacao and Sint Maarten is changing.

• Old alpha code: ANG (Netherlands Antilles Guilder)
• New alpha code: XCG (Caribbean Guilder)
• Numeric code: 532 (unchanged)
• Decimal places: 2 (unchanged)

This change ensures compliance with the latest currency standards for Curacao and Sint Maarten.

Transactions involving Curacao and Sint Maarten (currency code 532) will now use XCG instead of ANG.

Applicability

Enablement

Please prepare to receive the new alpha code XCG in the Transaction_Currency and Billing_Currency fields of FAST messages.

Note: this change is present from BL-2.23. Please refer to your production deployment schedule.

Technical info

The Transaction_Currency and Billing_Currency fields are found in the SUMMARY node of FAST request messages:

• "Transaction_Currency" : "XCG",
• "Billing_Currency" : "XCG",

AUTH-1138: New Merchant Category Code for Riyadh Air

A new Merchant Category Code (MCC ) 3169 has been introduced for Riyadh Air.

This code has been added to the relevant database to ensure the appropriate description in FAST request messages for this merchant.

Applicability

Enablement

Please prepare to receive the new MCC 3169 in FAST messages.

Note: this change is present from BL-2.23. Please refer to your production deployment schedule.

Technical info

The Merchant_Category field is found in the SUMMARY node of FAST request messages:

• "Merchant_Category" : "3169 - Riyadh Air",

DE18 (Merchant Category Code) is found in the ISO_MSG node of FAST messages:

• "DE18" : "3169",

PECA-682: New Mada tokenization client configuration: OTP (Yellow Flow) for app provisioning

In response to SAMA’s regulatory requirements, we have introduced a new client setting that allows Issuers to enforce OTP-based (Yellow Flow) authentication for app provisioning. Previously, app provisioning followed the Green Flow, but now clients can choose to require OTP verification for added security and compliance.

This update gives greater control and flexibility to clients who need to meet regulatory standards, ensuring a secure and compliant provisioning process while improving cardholder protection.

Applicability

Enablement

If you wish to have this setting enabled, please reach out to your Client Executive or raise a request via our Customer Support Platform.

Technical info

This setting can be enabled at the client level and will apply immediately once activated. If not enabled, provisioning will continue using the Green Flow.

PECA-693: Improved card enrollment reliability with automatic retry mechanism

We have introduced an automatic retry system for card enrollments that fail due to temporary network issues. This enhancement reduces failures and manual intervention by automatically retrying failed enrollment requests using a smart delay strategy.

The feature is configurable and can be enabled for clients who need it. Its benefits include:

• Higher success rates: Failed enrollments will now be automatically retried, improving overall completion rates.
• Less manual work: Reduces the need for support teams to manually reprocess failed enrollments.
• Stronger fraud & compliance protection: Ensures more cards are successfully enrolled in 3D Secure (3DS), reducing fraud risks and maintaining compliance with Mastercard’s data integrity standards (preventing potential fines).
• Automatic recovery from network issues: If an enrollment request fails, the system will retry it automatically instead of requiring manual intervention.
• Flexible configuration: The retry mechanism is not forced on all clients, it can be enabled only for those who need it.
• Smart retry strategy: The system waits longer after each failed attempt to avoid overloading the network.

Applicability

Enablement

If you wish to have this feature enabled and you’re using Paymentology's 3D Secure solution, please reach out to your Client Executive or raise a request via our Customer Support Platform.

PECP-430: Addition of link to PayControl user guide in PayControl

With the completion of the PayControl User Guide on the Developer Portal, we have added a link to this User Guide within PayControl itself. Increasing usability for PayControl users.

Applicability

Enablement

No enablement required.

Technical info

1. Under the Documentation sub-menu on PayControl, the main page of the User Guide is linked.
2. Instead of the tooltip found on each PayControl page, a link to the specific User Guide page on the Developer Portal is now linked.
3. Addition of a tooltip when hovering over a text string revealing more information. For example, you can now hover over a transaction filter to know more about its purpose.

AUTH-1126: Updating reason and response codes for ATC declines

The response code for ATC (Application Transaction Counter) declines has changed from 05 to 63.

Additionally, we have introduced a feature that prevents ATC declines for deferred authorization transactions on Mastercard when the feature flag is enabled.

Applicability

Enablement

No enablement required for response code changes for ATC declines.

If you wish to have the feature flag enabled that prevents ATC declines for deferred authorization transactions, and you are a Mastercard Issuer, please reach out to your Client Executive or raise a request via our Customer Support Platform.

Technical info

Response code 05 is a general response code, while response code 63 provides a more specific reason.

This change allows clients to access more accurate data when investigating reasons for decline.

You can read more on response codes here.

AUTH-1145: Issuer On-Behalf Services (OBS) 52 check for CVV validation

For tokenized transactions, if we receive OBS 52 (Mastercard Digital Enablement Service CVC 3 Pre-Validation) as valid and the PAN auto-entry via a magnetic stripe or contactless magnetic stripe, CVV validation will be skipped based on the OBS result.

This enhancement improves transaction efficiency by reducing unnecessary CVV checks when Mastercard’s pre-validation service (OBS 52) confirms it’s already valid.

Applicability

Enablement

No enablement required.

AUTH-1182: Enforce unique card check

As part of enforcing unique card checks for transactions, we have introduced a new Processor_Reason_Code: 131 – Multiple Card Record.

Transactions will be declined with response code (DE39) 05 if multiple records exist for the same card (ECNO).

Applicability

Enablement

Please prepare to receive the new Processor_Reason_Code and Processor_Reason_Desc.

Technical info

The Processor_Reason_Code and Processor_Reason_Desc fields are found in the SUMMARY node of the FAST request message.

They will display the below details in the event multiple records exist for the same card:

• "Processor_Reason_Code" : "131",
• "Processor_Decision_Desc" : "Decline - Multiple Card Record",

DEC-365: Additional transaction values available for whitelisting use in Check Merchant Activity rule

You are now able to whitelist specific values in the Check Merchant Activity Rule, allowing you to bypass the check in the current transaction.

This allows finer controls over the check merchant activity rule.

Applicability

Enablement

Please speak with our Fraud Team if you would like to include any whitelisting in the Check Merchant Activity rule.

Technical info

You can specify values related to the fields below:

• Merchant Category Code (MCC) (DE18)
• Acquiring Institution Identification Code (DE32)
• Card Acceptor Terminal Identification (DE41)
• Card Acceptor ID (Merchant ID) (DE42)
• Card Acceptor Name (DE43.1)
• Card Acceptor Country Code (DE43.5)
• Wallet ID/ SLI/ DI/DTI (DE48)

DEFECT-2534: Inclusion of client name in subject line of email notifications

When receiving email notifications from Paymentology Support ([email protected]) regarding file and report generation, the email Subject will now include the client’s name.

Applicability

Enablement

No enablement required.

Technical info

• Old email Subject: Message From Paymentology ([BL environment name])
• New email Subject: Message From Paymentology: [Client Name] [File/Report Name] ([BL environment name])

Example: Message From Paymentology: Bank101 embossing file transfer (BL 2.0 SHAREDEU-PROD)