Most issuer processors have moved to the cloud. Fewer have built for it. And fewer still have asked the question that determines whether global processing actually works: where, exactly, is your transaction being processed, and does it matter?
"In the cloud" has become the default answer to infrastructure questions. It signals progress, modernity, a departure from the data centre era. As an answer to whether a processing platform actually performs, it tells you almost nothing.
Two questions matter more: where is your transaction processed, and was the architecture designed to keep it there? The answers determine more about platform performance, regulatory readiness, and long-term optionality than almost any other infrastructure decision.
"In the cloud" doesn't tell you enough
The vast majority of issuer processors now run in the cloud. A significant proportion are running the same monolithic architectures they always did, just on rented infrastructure.
Cloud-hosted means exactly what it sounds like: a legacy platform moved to virtual machines in someone else's data centre. Scheduled deployment windows. Capacity provisioned for anticipated peaks. Single points of failure replicated faithfully from on-premise hardware into a different hosting environment.
Cloud-native is a different architectural model. The platform scales without always-on servers because it runs on serverless compute: capacity arrives when transactions do and disappears when they don't. Transactions are handled as discrete events rather than queued in batch jobs, so a volume spike doesn't back up behind a processing window. And because the design is stateless, a single component failing doesn't take the rest of the system with it.
For issuers, the distinction determines three things.
Resilience
In an active-active deployment across multiple availability zones, losing one region or component doesn't interrupt processing. Surviving capacity continues without a failover, without downtime. That's a different proposition from active-passive architecture, where recovery is measured in minutes or hours, and every declined transaction erodes cardholder trust that takes months to rebuild.
Scale elasticity
Cloud-hosted platforms provision capacity for anticipated peak volumes. When demand exceeds that provision, the platform degrades or declines transactions. Cloud-native platforms don't have that ceiling; they scale in response to real volume.
Deployment speed
When a card scheme introduces a new feature, cloud-native platforms can deploy support in days. Cloud-hosted platforms with scheduled release windows may take weeks or months. Over a year, that gap compounds into a material competitive difference.
Nearly every processor claims to be cloud-native. Few define what they mean by it. The right question isn't what a platform calls itself; it's how it behaves under load, failure, and change.
Where your transaction is processed is an operational question, not a geographic one
Latency is real, measurable, and it adds up.
When processing infrastructure is centralised in a distant region, every authorisation request travels further than it needs to: more latency, more failure points, more exposure when physical infrastructure degrades. Cross-border transaction rerouting when cables fail adds meaningful latency and reliability risk. That shows up in declined authorisations and frustrated cardholders, not in architectural diagrams.
This holds whether you're operating across Asia Pacific, Europe, or expanding from one region into another. A processor running a single European hub will struggle to serve clients with programmes across Southeast Asia, Australia, and Northeast Asia simultaneously.
Security has the same regional problem. Most processing platforms rely on physical hardware security modules (HSMs) for cryptographic work: PIN verification, card data encryption, key management. The hardware has to be somewhere. Adding a region means procurement cycles, dedicated facilities, and specialist staff before any card programme goes live.
Cloud-based HSMs deliver the same cryptographic functions (PCI PIN, PCI P2PE, PCI DSS compliant) as elastic, API-accessible services rather than fixed physical infrastructure, so the security layer inherits the same elasticity as the rest of the platform. Thredd's architecture is designed to minimise the requirement for transaction data to traverse regional borders; our Singapore regional hub keeps APAC transactions in APAC, improving authorisation speed and reducing cross-border exposure.
Regulation is catching up with architecture
The business case for regional processing is becoming a compliance requirement.
Data residency requirements are tightening across every major market. In January 2025, the EU's Digital Operational Resilience Act came into effect, imposing specific requirements on financial entities and their critical ICT providers, including processors. DORA doesn't recommend resilient infrastructure; it mandates it. Regional equivalents are following in Asia Pacific and beyond.
For issuers, this creates a tension that cloud-hosted platforms struggle to resolve. Global consistency requires a unified platform with shared configuration and operational standards. Local compliance requires regional processing, data storage, and scheme connectivity. Applied across multiple markets simultaneously, these requirements expose the limits of architectures designed for a simpler world.
Cloud-native architecture resolves the tension rather than forcing a trade-off. When regional deployment is a configuration decision rather than a re-engineering project, the same platform can maintain global consistency while meeting local requirements. The architecture was designed for this; the cloud-hosted monolith was not.
The schemes themselves are moving the same way. Visa Cloud Connect and Mastercard Cloud Edge are replacing decades-old network infrastructure with cloud-based connectivity. For processors with cloud-native architectures, this is a natural extension. For those bridging the gap with middleware, every scheme update creates new friction.
The practical test: expansion as a decision, not a project
The question that separates processors: can you enter a new market as a strategy call, or does it require an integration project measured in quarters?
Single-instance, multi-region architecture makes expansion a deployment decision. The same platform, the same configuration, deployed closer to where transactions originate. The platform follows the client's expansion; the client doesn't wait for the platform to catch up.
This is the landing zone model: architecture designed to follow markets rather than anchor transactions back to a central hub. Processing capability deployed into a new region as demand and regulatory conditions require, not as a roadmap commitment but as a property of how the platform was built. As cloud providers expand their regional footprints, the addressable deployment map grows with them.
Thredd is live on Visa Cloud Connect in APAC and working toward full cloud-native connectivity with Mastercard across markets. Optionality here isn't a roadmap promise; it's what falls out of architectural decisions made upfront.
The decision that compounds
The infrastructure decisions made now determine which platforms can adapt as markets, regulations, and payment rails evolve, and which ones become the next generation of legacy.
Cloud-native scheme connectivity is reshaping how processors connect to networks. Platforms that can integrate natively are in a structurally different position from those bridging the gap with middleware. The question "where is my transaction processed?" sounds operational. It is. But it's also how you can tell which category a platform falls into.
The organisations best positioned aren't the ones that moved to the cloud. They're the ones whose architecture was designed for it: event-driven, serverless, API-native, and built to process where transactions originate rather than where the platform was first deployed.
To read more about Thredd's implementation of Visa Cloud Connect in Asia Pacific, including the operational details of our Singapore regional hub, [see the full press release →]
