2 min read
How ObsidianTransact Supports Dynamic Card Updates Through EMV Issuer Scripts
From 2027, Mastercard recommends that issuers have the capability to update card offline spending parameters through issuer scripts.
For issuers, this creates a practical question: can their existing authorisation and EMV processing environments securely change scriptable parameters on cards already in circulation?
ObsidianTransact provides a managed link between transaction authentication, issuer policy and the card, covering script generation, execution reporting and controlled retry.
Why Offline Spending Parameters Need To Be Adjustable
Offline capability allows card transactions to proceed when online authorisation is unavailable. This supports payment continuity but also increases issuer exposure because the transaction cannot be assessed in real time.
Offline spending limits and other card risk-management parameters therefore need to balance resilience against risk. If these settings remain fixed throughout the card lifecycle, issuers have limited scope to respond to changes in account status, customer eligibility or risk policy.
EMV issuer scripts provide a mechanism for updating scriptable parameters without physically replacing the card. The script is generated by the Issuer, included in an online authorisation response and passed by the terminal to the card for execution.
The parameters that can be changed depend on the card application and personalisation profile. Successful delivery also depends on the card, terminal and authorisation path supporting issuer-script processing and result reporting.
Three Ways To Initiate An Update
ObsidianTransact sits within the Issuer’s EMV authorisation flow. In addition to verifying EMV application cryptograms, it can analyse transaction data (e.g. analysing TVR, CVR, ATC, etc.) and generate issuer scripts using three operating models.
1. Pre-staged updates
Cards may initially be issued with conservative offline spending parameters. An update can be prepared in advance and delivered during a subsequent eligible online transaction once defined eligibility, account-history or risk criteria have been met.
This allows issuers to introduce greater offline capability gradually and according to established policy.
2. Authorisation-driven updates
An issuer’s authorisation, fraud-management or risk platform may determine that a card parameter should change as part of the transaction flow.
The issuer platform retains responsibility for the decision. ObsidianTransact generates the required issuer script and includes it in the authorisation response. Issuers can therefore retain their existing decision logic without requiring the authorisation host to construct EMV-specific scripts.
3. EMV-data-driven updates
The platform can analyse EMV transaction data, including Card Verification Results and Terminal Verification Results.
Configurable rules can identify defined transaction conditions and initiate the appropriate script. This reduces the need for the issuer host to interpret detailed EMV data for every card-management scenario.
Managing Script Delivery
Including a script in an authorisation response does not guarantee successful execution. Delivery may fail because of transaction conditions, terminal behaviour, card status or communication issues.
ObsidianTransact manages the script beyond its initial generation. Pending or unsuccessful scripts can be retained for delivery during a later eligible online transaction. Where several scripts are waiting, the highest-priority update will be delivered first.
Execution results returned through transaction data allow the platform to update the status of each script and determine whether further delivery attempts are required.
This gives issuers a controlled process for generating, delivering, monitoring and retrying card updates across large portfolios.
A Managed Approach to Offline Card Controls
Where the relevant card profiles and transaction paths support issuer scripts, issuers can introduce offline capability conservatively, adjust spending parameters over time and respond to changing risk conditions without relying solely on card replacement.
ObsidianTransact provides the managed connection between issuer decisions and secure updates to the card. It enables issuers to use their existing authorisation and risk systems while adding the EMV-specific processing and lifecycle controls needed to support Mastercard’s recommendation.
Cryptomathic can help issuers assess their current EMV environment and establish a controlled approach to managing offline card parameters ahead of 2027.
From Issuer Policy to Controlled Card Update
How Obsidian Transact generates, delivers and manages EMV Issuer scripts:
Prepare Your Card Update Strategy For 2027
Mastercard’s 2027 recommendation makes dynamic card updates an increasingly important part of issuer readiness. With ObsidianTransact, issuers can securely generate, deliver and manage EMV issuer scripts within their existing authorisation environment. Explore how ObsidianTransact can help you manage card updates securely and at scale.