Blog

AI in Payments: Solving the Enterprise Execution Problem - Opus | Engineering the NEXT

Prakash.Dev@opustechglobal.com (The Opus Desk) — Wed, 28 Oct 2026 15:47:00 GMT

Artificial intelligence is rapidly reshaping the payments industry’s underlying architecture and redefining the user experience. Yet, while AI adoption is accelerating, the journey from promising pilots to scaled business outcomes remains far from straightforward.

The New Rules of Enterprise Technology Buying in the AI Era - Opus | Engineering the NEXT

Prakash.Dev@opustechglobal.com (The Opus Desk) — Thu, 22 Oct 2026 15:50:00 GMT

To explore how enterprise buying decisions are evolving in the AI era, Opus Technologies Chief Revenue Officer Prakash Devulapalli sat down with industry analyst Ronak Doshi, Partner at Everest Group.

“Start With the Outcome, Not the Execution” - Opus | Engineering the NEXT

Prakash.Dev@opustechglobal.com (The Opus Desk) — Mon, 19 Oct 2026 16:09:00 GMT

As AI changes how software is planned, built, tested, and delivered, engineering organizations have an opportunity to rethink what successful delivery really means. Faster execution matters, but speed alone does not create business value. The real measure is whether engineering solves the customer’s problem and improves the outcomes that matter.

Side-by-Side Tokenization: Enabling Merchant Routing Choice - Opus | Engineering the NEXT

Debashis.Bh@opustechglobal.com (Debashis Bhattacharyya) — Mon, 19 Oct 2026 10:26:00 GMT

Tokenization Leads to a Network routing Paradox

Tokenization solved an important security and regulatory problem in digital payments: merchants no longer need to retain the underlying Primary Account Number (PAN) to support card-on-file (COF) transactions.

But it created another problem – routing control.

A merchant may have a debit card that can legitimately route over multiple enabled debit networks. Yet when the merchant stores a network token issued by a front-of-card network, that token may carry network or processing restrictions. The merchant therefore loses the ability to choose an alternate debit network for a subsequent digital tokenized transaction.

“The merchant has more security, but potentially less routing choice.” – Debashis Bhattacharyya

Side by Side Token – an Introduction

A side-by-side token architecture addresses that problem by allowing multiple network-specific tokens representing the same underlying payment account to coexist. It gives the merchant the ability to select the appropriate token and therefore the network route dynamically during transaction processing.

This concept is based on an important design principle that maintains three relationships –

Payment Identity – PAN and Account
Token Identity – Primary and Secondary tokens
Network Routing

PULSE’s Side-by-Side (SXS) Token Service is a real-world example of this model. PULSE describes SXS as enabling tokenized card-on-file debit transactions to be routed over PULSE or another participating unaffiliated debit network, with cryptogram validation and no change to the cardholder experience.

The objective of this article is not to reproduce PULSE’s implementation. Instead, it uses the publicly available patent disclosures as a reference architecture for how a new debit network could build its own side-by-side token capability.

The Problem – Tokenization dictating routing

Consider a consumer who has a debit card issued by Bank A.

That card supports:

Network A: Front-of-card network
Network B: An alternative debit network

A merchant stores the customer’s card for future purchases. Traditionally, the merchant token comes from the network.

Customer PAN -> Front of Card Token Service -> Merchant Token -> Merchant Card on File

For security reasons, that token may be restricted to transactions routed through the network that issued it. Hence, the transactions are always routed through Network A.

The Solution – Side by Side Token

The core idea of this solution is simple. Let us use the same scenario here as well. In this case, two tokens are generated and stored at the merchant. One for the front of card – A, and an additional for the Debit Network – Back of card – B.

Please note – they are co-existent but not interchangeable. They have their own Token PAN, token type, network association, lifecycle status, routing eligibility, relationship with the PAN and are independent of each other.

The merchant’s payment platform can then select the appropriate token according to its routing strategy as depicted in this diagram.

Reference Architecture

Functional and Token Workflow

Provisioning and Eligibility

Check Card eligibility for Secondary Tokenization. Currently it is done via BIN/account-range capability file but can be extended to product/issuer identifiers.
Provision the secondary token via the Debit Token Service. The token is sent to the merchant hiding the PAN as

{

“token”: “NDN_TOKEN_123456789”,

“token_type”: “SECONDARY”,

“network”: “NDN”,

“status”: “ACTIVE”,

“cryptogram_required”: true

}

The merchant saves this information in the database along with the primary token procured before from the Primary network.

The network also needs to support complete token lifecycle management. Events like Update, Suspend, Expire, Delete etc. need to be supported. The network can also provide Account Updater services to compliment the lifecycle management services. This will ensure issuers are able to send replacement tokens to merchants or processors to maintain uninterrupted COF relationship.
The network also should keep a log of the token requestor. This will ensure the network understands – who requested the token, associated merchant, applied use cases, network route and privileges of the requestor.

Merchant View, Routing and Processing

The merchant now has multiple payment credentials associated with the same customer payment account.

The customer is invisible to this information, as they see the last 4 digits in the token on screen at the merchant’s e-commerce portal.

The merchant needs to build a routing engine based on the rules and network preference that can take advantage of this capability. The idea is for the merchant to be able to choose between the two tokens to maximize profits and minimize costs both for themselves and the customer without degrading the customer experience. The routing engine can route based on many factors –

Transaction Cost
Authorization Performance and Approval %
Network Reliability
Preference of the merchant
Other characteristics like recurring, CNP, amount, MCC, Issuer etc.

A simple NDN based transaction will look like this

The presence of a secondary token should not be the reason for routing through NDN. It should be based on rules owned and managed by the merchant.

Debit Network Enablement – Capabilities

The debit network needs to carefully design a monetization policy that incentivizes merchants for routing through them. This can be made lucrative through lower cost, flexibility, safety and performance.

The table below lists the capabilities required by the network for enablement. These can be prioritized by applying the MoSCoW principle.

Capability	Purpose
Token Service	Generate/manage secondary tokens
Eligibility Directory	Determine which cards/accounts support NDN
Token Vault	Secure PAN-to-token mapping
Cryptogram Service	Generate/validate transaction cryptography
Token Requestor Management	Control who can provision tokens
Lifecycle Management	Suspend, resume, replace and expire tokens
Account Updater	Propagate account changes
Merchant APIs	Provisioning and lifecycle integration
BIN/Account Range APIs	Eligibility
Routing Integration	Enable merchant network selection
Authorization Gateway	Process NDN token transactions
Monitoring/Fraud	Detect token abuse
Dispute/Chargeback Mapping	Link token transactions to underlying account
Reporting	Token/network/merchant analytics
Monetization	Fees for provisioning, lifecycle management, transactions, VAU and VAS

Conclusion

The Side-by-Side token is a choice, and flexibility a merchant demands in today’s world. It empowers the merchant. It allows them to own and manage their routing mechanism and provide better services to their customers through low-cost routing options. The value is “One payment account can have multiple secure, lifecycle-managed network credentials, while the merchant retains the ability to choose the network route.”

Explainable AI in Finance: A Practical Guide to AI Governance - Opus | Engineering the NEXT

shefali.vasave@opustechglobal.com (Shefali Vasave) — Thu, 15 Oct 2026 15:59:00 GMT

Explainable AI in Finance: A Practical Guide to AI Governance and Compliance

AI-Enabled Quality Engineering: Catch Defects Earlier - Opus | Engineering the NEXT

Abhishek.Ojha@opustechglobal.com (Abhishek Ojha) — Fri, 09 Oct 2026 07:46:06 GMT

In any large migration project, multiple engineers may be working across dozens of modules at the same time. That creates two recurring bottlenecks in pull request (PR) review: volume and rework. Reviewers have too many submissions to examine thoroughly, while a meaningful share of those submissions require several rounds of changes because of standards violations, incomplete implementations, or non-compliant patterns that could have been caught earlier.

Digital Transformation for Financial Services: New Issuer Agenda - Opus | Engineering the NEXT

Shrikant.Khutwad@opustechglobal.com (Shrikant Khutwad) — Thu, 08 Oct 2026 11:11:40 GMT

The payments ecosystem is entering a structural shift. The forces reshaping it are increasingly coming from outside the traditional issuer-led modernization agenda. Network rule changes, regulatory empowerment, open banking mandates, platform regulation, agentic commerce, and the rapid growth of account-to-account and instant payment alternatives are giving merchants more choice and greater influence over how payments are initiated, routed, authenticated, and priced.

AI Automation for Financial Services: RPA vs Agentic AI - Opus | Engineering the NEXT

shefali.vasave@opustechglobal.com (Shefali Vasave) — Thu, 08 Oct 2026 06:46:14 GMT

The story usually told is that agentic AI replaces robotic process automation (RPA), but the data doesn't really support that. In the 2025 EY-Parthenon Generative AI in Banking survey, around 100 leading retail and commercial banks were asked about their automation estates, and only 28% of the automation use cases in development or production use generative or agentic AI at all. Traditional machine learning and RPA account for the other 72%, and they will continue to do so for a while. 

Simplify Backend Architecture by Removing Unnecessary Layers - Opus | Engineering the NEXT

Abhishek.Ojha@opustechglobal.com (Abhishek Ojha) — Tue, 06 Oct 2026 09:48:44 GMT

Every architectural layer in a system pays rent. It must justify its existence through functionality that cannot be delivered more simply elsewhere. When a layer remains because it was created under earlier constraints, even though the system has evolved around it, that layer becomes accidental complexity: infrastructure that consumes maintenance effort without providing proportional value.

Multi-Agent Systems in Banking: The Future of AI for the Industry - Opus | Engineering the NEXT

shefali.vasave@opustechglobal.com (Shefali Vasave) — Mon, 05 Oct 2026 08:54:57 GMT

A bank running fraud detection, credit decisioning, and dispute resolution today is probably running three AI models. It is also probably running three models that have never exchanged a single piece of context. The fraud model does not know that the credit model flagged the same account last week. The dispute agent rebuilds a case file that the fraud system has already assembled. Each model is accurate on its own. But when the decisions depend on context from other systems, accuracy in isolation does not always produce an accurate outcome.