Correctness Preserving Transport Layer and How it Fixes Payments
By Douglas E. Fisher, Founder, Zero Trust Event Systems
CPTL: The Missing Layer of the Internet that Fixes Payments
For fifty years, global payments have been built on a quiet assumption:
The transport layer is trustworthy.
Messages are assumed to be honest, complete, in order, and unmodified.
Every fraud tool, every dispute process, every reconciliation team, every audit trail is built on top of that assumption.
And it’s wrong.
The result is the world we live in today:
-
Fraud is a permanent line item.
-
Disputes and chargebacks are a cost of doing business.
-
Reconciliation is a full‑time job.
-
Audits are painful and incomplete.
-
Everyone—issuer, acquirer, merchant, network—sees a slightly different version of “what happened.”
CPTL (Correctness Protocol Transport Layer) is a new layer of the internet—Layer 4.5—that fixes this at the root.
It doesn’t replace ISO 8583, ISO 20022, EMV, or RTP.
It wraps them. It strengthens them. It makes them provable.
The root cause: we can’t prove what actually happened
Fraud, disputes, reconciliation, and audit failures all share one root cause:
The ecosystem cannot cryptographically prove what actually happened.
Today’s payment events are:
-
Not actor‑bound — we can’t prove which human actually initiated the event.
-
Not device‑bound — we can’t prove which device actually sent it.
-
Not payload‑bound — we can’t prove the amount, merchant, or details weren’t changed in flight.
-
Not sequence‑bound — we can’t prove where this event sits in a timeline, or whether it was replayed, duplicated, or inserted.
Because we can’t prove those things, we compensate with:
-
CVV, AVS, 3‑D Secure
-
fraud scoring and machine learning
-
manual reviews
-
chargebacks and reason codes
-
reconciliation teams
-
audit reconstruction
-
endless logs and evidence gathering
All of that is expensive, fragile, and still doesn’t give us certainty.
CPTL changes that.
CPTL in one sentence
CPTL is a transport‑layer correctness substrate that cryptographically binds every event to:
-
the actor (who)
-
the device (from where)
-
the payload (what)
-
the sequence (when/where in the timeline)
If any of those change, the proof breaks.
That’s it. That’s the hammer.
How CPTL works (without getting lost in math)
Every CPTL event carries:
-
Actor ID — the logical identity (cardholder, merchant, issuer, etc.)
-
Device ID — the physical/virtual endpoint (phone, POS, browser, HSM, etc.)
-
Payload — the business content (amount, merchant, currency, timestamps, etc.)
-
Sequence — a monotonic sequence number and a hash of the previous event
-
Proof — cryptographic signatures and hashes over all of the above
Under the hood, CPTL does four things.
1. Actor binding
The actor (for example, the cardholder) has a cryptographic key that lives in secure hardware (secure enclave, secure element, TEE, etc.).
-
The user never sees the key.
-
The user never types the key.
-
The key never leaves the device.
When they authorize a payment (online or in‑store), the secure hardware signs the event hash.
If the actor signature verifies, the issuer can say:
“This event was authorized by this actor’s key.”
2. Device binding
The device (phone, POS, browser, terminal) also has its own key.
It signs the same event hash.
If the device signature verifies, the ecosystem can say:
“This event came from this specific device.”
Even if an actor key were compromised, the device binding still matters: unusual devices, new devices, or revoked devices stand out immediately.
3. Payload binding
CPTL hashes the entire payload:
-
amount
-
merchant
-
currency
-
timestamps
-
tokens/PANs
-
any other business fields
That hash is what gets signed.
If anyone changes the amount, merchant, currency, or any other field, the hash changes and the signatures no longer verify.
No silent mutations. No “it changed somewhere along the way.” No “our logs don’t match theirs.”
4. Sequence binding
Each actor (and/or device) has a monotonic sequence:
-
1, 2, 3, 4, …
Each event includes:
-
a SequenceNumber
-
a PrevHash (the hash of the previous event)
This creates a hash chain.
You can’t:
-
insert an event in the middle
-
delete an event without detection
-
replay an old event as new
-
reorder events without breaking the chain
The timeline becomes cryptographically anchored.
When you can’t prove who did what, from where, with what payload, at what point in time, you’re forced to guess. That’s fraud scoring, 3‑D Secure, CVV, AVS, and all the rest.
With CPTL:
What this does to fraud, disputes, reconciliation, and audits
Once every event is bound to actor, device, payload, and sequence, four big things happen.
Fraud collapses
Fraud thrives in ambiguity.
-
If the actor and device signatures verify, and the sequence is correct, the issuer can say with high confidence:
-
“This really was the cardholder on their device, with this payload, in this sequence.”
-
If they don’t verify, the event is rejected before it ever becomes a transaction.
Fraud moves from “statistical” to “cryptographically constrained.”
Disputes and chargebacks collapse
Most disputes exist because no one can prove what actually happened.
-
The cardholder says “not me.”
-
The merchant says “yes it was.”
-
The issuer shrugs.
-
The network mediates.
-
Everyone burns time and money.
With CPTL, the issuer has a correctness profile for every event:
-
Actor binding: Strong / Weak / None
-
Device binding: Strong / Weak / None
-
Payload binding: Strong / None
-
Sequence binding: Strong / Merchant‑side / None
-
Overall event strength: High / Medium / Low
If an event has strong actor, device, payload, and sequence binding, the issuer can treat disputes very differently than a low‑strength event with no actor binding and weak device binding.
Ambiguity shrinks. So do chargebacks.
Reconciliation collapses
Reconciliation exists because different parties see different versions of the same event.
-
The merchant’s records don’t match the acquirer’s.
-
The acquirer’s don’t match the network’s.
-
The network’s don’t match the issuer’s.
-
Everyone has their own logs, their own timestamps, their own IDs.
CPTL enforces a single canonical event:
-
one event hash
-
one payload hash
-
one sequence position
-
one lineage
If the hashes match, you’re looking at the same event.
If they don’t, something is wrong—immediately, not months later.
Reconciliation becomes trivial or unnecessary.
Audits become boring (in a good way)
Audits fail when:
-
logs are missing
-
events are duplicated
-
timestamps drift
-
evidence is incomplete
-
lineage is unclear
CPTL gives you:
-
tamper‑evident event chains
-
provable sequence
-
provable payload integrity
-
provable actor/device binding
Auditors don’t have to reconstruct history from partial logs.
They can verify a cryptographic history that either checks out or doesn’t.
CPTL doesn’t replace ISO 8583 or ISO 20022—it wraps them
This is where CPTL becomes practical instead of academic.
ISO 8583
ISO 8583 is the legacy card‑payments message format: bitmaps and fields.
CPTL doesn’t change it. It treats the entire 8583 message as the payload:
-
CPTL.Payload = ISO8583Message
CPTL then:
-
hashes the 8583 message
-
signs it with actor and device keys
-
chains it into a sequence
Result:
-
Field 4 (amount) can’t be silently changed.
-
Field 2 (PAN/token) can’t be changed.
-
EMV data can’t be changed.
-
No field can be changed without breaking the proof.
ISO 8583 becomes tamper‑evident for the first time in its history.
ISO 20022
ISO 20022 is the modern XML/JSON‑based financial messaging standard.
Same story:
-
CPTL.Payload = ISO20022Message
CPTL binds:
-
debtor/creditor
-
amount
-
remittance info
-
timestamps
-
message IDs
-
sequence
Result:
-
no silent mutations
-
no missing messages
-
no undetected duplicates
-
no ambiguous lineage
20022 becomes cryptographically trustworthy, not just structurally rich.
CPTL collapses entire categories of compensating controls
Because CPTL fixes correctness at the transport layer, many things we treat as “necessary” today become optional or obsolete:
-
3‑D Secure
-
CVV
-
AVS
-
many fraud scoring heuristics
-
much of manual review
-
most chargebacks
-
most reconciliation
-
a lot of audit reconstruction
Those tools exist to compensate for the fact that we can’t prove what actually happened.
Once we can, they shrink dramatically.
That doesn’t mean everything disappears overnight—but the direction of travel is clear: less guesswork, more proof.
Why regulators and standards bodies will like CPTL
CPTL is shaped to fit into the existing ecosystem instead of fighting it.
-
EMVCo can define an EMV‑CPTL spec that wraps EMV data and cryptograms without breaking terminals or cards.
-
PCI‑DSS can recognize CPTL as an approved method of achieving transaction correctness, reducing the need for many compensating controls.
-
Networks can mandate CPTL for high‑risk flows (CNP, cross‑border, high‑fraud MCCs) and then broaden from there.
-
Issuers and acquirers can adopt CPTL incrementally—first for device‑bound flows (wallets, apps), then for merchant terminals, then more broadly.
CPTL is:
-
backward‑compatible
-
protocol‑agnostic
-
domain‑agnostic
-
cryptographically sound
-
operationally meaningful
It doesn’t ask the world to throw away its rails.
It asks the world to make those rails provable.
What this means for the workforce
When correctness is native:
-
Fewer people are needed for reconciliation.
-
Fewer people are needed for dispute handling.
-
Fewer people are needed for manual fraud review.
-
Fewer people are needed to reconstruct history for audits.
Those people don’t disappear—they move up the value chain:
-
designing better products
-
improving customer experience
-
analyzing real trends instead of chasing mismatched logs
-
focusing on strategic risk instead of tactical cleanup
CPTL doesn’t just reduce waste.
It frees human beings from low‑leverage, high‑frustration work.
The big picture: a new layer of the internet
CPTL is more than a payments feature.
It’s a new layer:
-
below ISO 8583 and ISO 20022
-
below EMV and RTP
-
above TCP/UDP/QUIC
Layer 4.5: the correctness layer.
For payments, it means:
-
fewer fraud losses
-
fewer disputes
-
fewer chargebacks
-
fewer reconciliations
-
cleaner audits
-
simpler compliance
-
higher approval rates
-
lower operational cost
For the broader internet, it opens the door to:
-
fewer fraud losses
-
fewer disputes
-
fewer chargebacks
-
fewer reconciliations
-
cleaner audits
-
simpler compliance
-
higher approval rates
-
lower operational cost
Anywhere we care about “what actually happened,” CPTL’s model applies.
Closing
For decades, we’ve tried to fix payments by adding more checks, more scores, more flags, more processes.
CPTL takes a different approach:
Fix correctness once, at the transport layer, and let everything above it get simpler.
Actor, device, payload, sequence—cryptographically bound, or the event doesn’t count.
That’s the idea.
And once you see it, it’s hard to unsee how much unnecessary complexity it can collapse.
Douglas E. Fisher
Founder, Zero Trust Event Systems
June 2026
06/25/2026
CPTL / Capitol — Pre‑v1.0 Operational Status The Correctness‑Preserving Transport Layer is now operational in a pre‑v1.0 state.
The IPC‑based control plane and tunnel endpoint are live and executing successfully in controlled testlab conditions. The transport substrate is now capable of carrying real traffic through the correctness boundary, enabling end‑to‑end validation of transport‑layer semantics.
Full v1.0 release will follow after extended verification, load testing, and integration with the broader ZTES correctness ecosystem.