Bridging Issuers, BankCore, and IDEMIA: a Secure-Message Orchestrator That Stays Out of PCI-DSS Scope

For most of late 2025 and into early 2026, I was building a system at Telered that on paper looks like a card-payments project — but in practice is a secure-message orchestrator. The difference matters, because it's the entire reason the architecture works the way it does.

Our payment processing involves three independent systems that need to talk to each other:

• Issuers — the banks issuing the cards (multiple of them, each with their own protocol dialect)
• SVBankCore — Telered's internal core-banking platform
• IDEMIA — the third-party that personalizes physical cards and runs adjacent services

The orchestrator sits in the middle. It doesn't store cards, doesn't generate tokens, doesn't try to be a vault. It re-shapes one system's request into the format another system expects, signs it, encrypts it, hands it off, and shepherds the response back through the same pipeline in reverse.

Sounds simple. The interesting parts are in what we deliberately didn't build.

Why we don't store tokens (and why that's the right call)

The obvious-looking design for "we have card data flowing through us" is to build a token vault: receive a PAN, hash it through KMS, hand back a token, store the mapping. Every other system upstream then references the token instead of the PAN.

That's a perfectly fine design. It's also a massive PCI-DSS scope expansion.

The moment you store cards (even encrypted), you inherit:

• A vault stack that has to pass formal QSA audit
• KMS configuration with documented key-rotation procedures
• Network segmentation around the vault zone
• Annual penetration tests on the vault path
• Logging and audit-trail infrastructure that survives a forensic review
• Process discipline (change-control, separation-of-duties, etc.) for everyone with vault access
• Ongoing ISO compliance work that touches every system the vault data flows into

For Telered, taking that on would have meant rebuilding compliance posture across half the organization — including parts of SVBankCore that the regulator currently lets us operate as-is. The math didn't work.

So the brief I got was the opposite: don't expand PCI scope, period. The orchestrator must broker messages without ever owning sensitive data at rest.

The architecture, in one diagram

        Issuer A ─┐
        Issuer B ─┼─▶ ┌──────────────────────┐
        Issuer C ─┘   │                      │      ┌──────────────┐
                      │      Orchestrator    │ ◀──▶ │ PaymentGateway│ ◀──▶ SVBankCore
                      │  (Node.js on AWS)    │      │   (Java)      │      (core banking)
                      │                      │      └──────────────┘
                      └──────────┬───────────┘
                                 │
                                 ▼
                              IDEMIA
                       (card personalization)

Two services, one project: the Orchestrator is Node.js running on AWS — that's the message hub the issuers and IDEMIA talk to. The PaymentGateway is a Java service that adapts SVBankCore's protocol to/from whatever shape the orchestrator wants to see. Splitting them lets each side evolve at its own pace: the orchestrator stays close to the modern AWS stack, the PaymentGateway stays close to SVBankCore's idioms (which are decidedly not modern). Neither service stores card data at rest.

A request enters from any of the issuer sides. The orchestrator:

1. Authenticates the sender — mTLS to issuers, signed payloads to/from IDEMIA, internal IAM for SVBankCore
2. Re-shapes the message — issuer A sends a 200-field structured message, IDEMIA expects a 70-field one, the relevant 65 fields map across with some logic in between
3. Re-signs and re-encrypts for the destination — every hop has its own certificate trust and encryption envelope; messages in flight at one hop are unintelligible at another
4. Forwards with a correlation ID so the response can find its way home
5. Logs the metadata (who, when, which message type, success/failure) — but never the body

The body never lands at rest in our infrastructure. CloudWatch sees correlation IDs and result codes, never PANs.

What "in scope" still means even without storing cards

Even though we don't store card data, we do transit card data. That keeps us in PCI-DSS scope as a service provider — which is far less burdensome than being a vault, but isn't zero. We still:

• Use TLS 1.2+ for every hop, with strict cipher suites
• Pin certificates where the counterparty supports it
• Have a documented incident response plan
• Run quarterly internal vulnerability scans
• Keep production access on a documented allowlist

But — critically — our auditors aren't reviewing how we protect cards at rest, because there are no cards at rest. The scope is the network path and the application code, not a database.

What I underestimated going in

A few things bit harder than I expected:

The signing and encryption layer is more code than the routing layer. Each counterparty has their own certificate trust expectations, key-rotation schedules, and message-format quirks. At one point we had three flavors of "is this signature valid right now" because three vendors disagreed on what now means in terms of certificate validity windows.

Idempotency is harder than it sounds when you don't own the destination's state. If a message to SVBankCore times out at the network layer, did it land or not? You can't ask SVBankCore "are you in the same place I left you" without a side channel — so we built one, tied to the correlation ID. Most of the bugs we caught during dogfooding were in this path.

Observability without data leakage is its own design problem. The natural urge when debugging a failed message is to log the message. But "the message" contains card data. We invested early in a structured event vocabulary — outcomes, error codes, hop timings, never bodies — so engineers could diagnose 90% of issues without ever needing to see a PAN.

What I'd do differently

If I started over, I'd push harder on per-counterparty test fixtures. We had a great staging integration with one issuer and a less-great integration with the others, which meant integration bugs surfaced asymmetrically. A tighter contract-test suite per counterparty would have caught a chunk of the staging-vs-prod drift earlier.

I'd also invest sooner in a replay tool. Once messages started flowing, the most useful debugging tool turned out to be "give me the correlation ID for this failed thing and replay it through the orchestrator with debug logging" — but we built that under fire after the first incident, when we should have built it on day three.

The framing that matters

The interesting work in payment integration isn't usually the cryptography (KMS does it, you don't write it) or the routing (it's a switch with a few branches). It's the scope discipline: how much sensitive data do you let near you, and how confidently can you prove to an auditor that you stayed on the right side of that line?

Building an orchestrator that stays out of vault scope is a different design exercise than building a vault. It's also, for our particular constraints at Telered, the better one. PCI-DSS scope is contagious — once it spreads to your codebase, you don't get rid of it. Choosing not to catch it in the first place is the lever with the highest leverage on long-term compliance burden.

Tokenization is interesting work, and someone in the payments stack should do it. It just doesn't have to be us.