Request access
Pre-settlement verificationAgentic payment securityQuantum-safe paymentsDeepfake & APP fraudVerifiable attestationHow it worksAll payment railsRTP fraud preventionFedNow fraud preventionStablecoin securityTokenized depositsOn-chain settlementBanks & credit unionsFintechs & PSPsStablecoin issuersCrypto custodiansCorporate treasuryMarketplaces & platformsWhy RankShield FinancialAuthorized push payment fraudCEO & wire fraudAI-agent payment risksHarvest now, decrypt laterData protectionComplianceSecurityAboutRequest access
RankShield Network · Financial · RTP rail

RTP settles in seconds.verify before it does.RTP fraud prevention from RankShield Financial verifies each real-time payment intent before it settles on The Clearing House rail. Because RTP is instant, 24/7, and irrevocable, it normalizes the ISO 20022 instruction into a canonical intent and returns a released or held verdict pre-settlement.

Request accessSee pre-settlement verification
iso 20022 normalizedcredit-push · irrevocableverified pre-settlement
rail normalizer · native → canonical intent
# native RTP instruction
debtor: acct-04f2
creditor: acct-1180
amount: 48500.00
ccy: USD
e2e: e2e-7c19a3
↓ normalize + de-identify
rs-fin-intent-v1|rail=rtp|amount_minor=4850000|payer=<commit>|payee=<commit>
digest
…
one canonical intent, one signature path — whichever rail the money moves on.
01 // Rail
The rail

What is RTP and why does it need pre-settlement verification?

RTP is the Real-Time Payments network operated by The Clearing House — the first new US payments rail in decades — carrying credit-push payments that settle instantly, run 24 hours a day every day of the year, and are irrevocable once sent. Those same properties are why RTP needs a different kind of defense. A card charge can be disputed; an ACH debit can be returned; an RTP credit-push cannot be reversed by the sender. When a fraudulent payment settles in seconds with finality, every control that runs after settlement is investigating a loss rather than preventing one. RankShield Financial verifies the intent before the payment is released, in the only window where interception actually protects the funds. That is the core of real-time payments fraud defense: move the check upstream of finality, because on RTP there is no clawback to fall back on.

Compare all six payment rails
Instant
RTP settles with finality in seconds — there is no processing window to intervene in after send.
24/7
Always on, every day of the year — fraud does not wait for business hours, and neither can the check.
Irrevocable
A credit-push payment cannot be reversed by the sender — the only real control runs before release.
02 // Irreversible
Why upstream

Why does irreversibility make post-settlement controls too late?

Irreversibility removes the safety net that most fraud programs quietly rely on. On card and ACH rails, a mistake or a fraud can often be unwound — a chargeback, a return, a reversal — so a control that fires shortly after the payment still has a path to recover funds. RTP has no such path. Once a credit-push settles, the money is at the recipient and the sender cannot pull it back. That means a fraud score computed after send, an alert reviewed the next morning, or a batch reconciliation run overnight are all, structurally, too late to protect the payment. RankShield Financial responds by doing the work in the pre-settlement window: normalize the intent, verify identity and authority, resolve released or held, and only then let the payment proceed. The verdict lands while the payment is still stoppable, which on an irrevocable rail is the only moment that counts.

Control timingOn reversible railsOn RTP (irrevocable)
After settlementChargeback or return can recover fundsNo reversal — the money is gone
Fraud score post-sendTime to intervene before finalityFinality already reached in seconds
Overnight reconciliationNext-day correction is possibleToo late to protect the payment
Pre-settlement verificationAdds a verifiable gateThe only control that prevents loss
How the released-or-held verdict works
03 // Normalize
One canonical intent

How does RankShield normalize an RTP payment into a canonical intent?

RankShield takes the native ISO 20022 RTP instruction — debtor, creditor, amount, currency, end-to-end identifier — and reduces it to a single canonical intent record, the same shape used for every rail. That record is hashed to one digest and signed with composite ML-DSA-65, so an RTP payment is verified with exactly the same released-or-held logic as FedNow, stablecoin, tokenized deposit, CBDC, or on-chain. Normalizing to one intent means there is a single verifiable standard rather than a bespoke, weaker control per network. The instrument here makes it visible: pick RTP, watch the ISO 20022 fields collapse into one canonical intent and one digest, then switch rails and see the same verification run unchanged. That common shape is what lets a bank or fintech extend RTP without inventing a separate fraud stack for it.

rail normalizer · native → canonical intent
# native RTP instruction
debtor: acct-04f2
creditor: acct-1180
amount: 48500.00
ccy: USD
e2e: e2e-7c19a3
↓ normalize + de-identify
rs-fin-intent-v1|rail=rtp|amount_minor=4850000|payer=<commit>|payee=<commit>
digest
…
one canonical intent, one signature path — whichever rail the money moves on.
04 // APP fraud
Authorized-push-payment

How does RankShield stop APP and CEO fraud on RTP?

APP and CEO-impersonation fraud both work by convincing a legitimate user to approve a payment to an attacker — and on RTP that approved push settles instantly and cannot be recalled. RankShield verifies the intent and its approval before release, so a payee outside the normal pattern, an amount beyond granted authority, or a missing or synthetic liveness signal causes the payment to be held rather than settled. It treats the approval as something to prove, not assume. APP and crypto-rail scam losses were estimated around $10 to 12 billion a year in the 2024 range — an estimate, not a precise figure, but one that shows why intercepting these on an irrevocable rail matters. The held verdict routes a suspect payment back to a human or a stricter quorum while the money is still in place.

The impersonated executive

A finance user is pushed to send an urgent RTP payment

A convincing message and a follow-up call impersonate a senior executive, pressuring a finance user to approve an urgent RTP transfer to a new counterparty before anyone else can check it.

RankShield: the intent must clear pre-settlement verification in the app's own verified channel; the unfamiliar payee, the out-of-authority amount, or a replayed liveness response resolves to held, so the irrevocable push never settles.
~$10–12B/yr
Estimated 2024-range APP and crypto-rail scam losses — why interception must happen before settlement.
05 // Liveness
Honest boundary

Where does deepfake liveness actually work on RTP flows?

Deepfake liveness in RankShield works inside the app's own verified channel, and nowhere else — a boundary we state plainly rather than blur. When an RTP payment needs a human approval, the liveness check uses a one-time challenge nonce that resists replay, a detector verdict that must be cryptographically signed by an enrolled detector identity, and media bound one-to-one to the specific intent. A replayed or synthetic response is treated as synthetic and the payment is held. What it does not do is analyze a live carrier or FaceTime call; RankShield cannot inspect the phone network. So against a CEO-impersonation deepfake, the defense is to require the approval through the verified channel — where synthetic media fails the signed, nonce-bound check — not to claim it can watch the call the attacker placed. Honest scope is the point: the control is strong precisely where it operates, and we do not overstate where that is.

RankShield Network · pre-settlement ledger
RTP $48,500 invoice · acct ••42anchored ✓
AGENT $1,200 ap_7f3 · vendoranchored ✓
WIRE $96,000 “CEO” call · livenessheld · deepfake
FEDNOW $7,310 payroll · acct ••08anchored ✓
USDC 500.00 0x9f…c1 → 0x2a…7eanchored ✓
verified BEFORE settlementml-dsa-65 · anchored
More on authorized-push-payment fraud
06 // On RTP
What RankShield adds to RTP

Four controls on every RTP payment.

RankShield does not slow RTP down with a manual queue. It adds a verifiable, cryptographic gate in the pre-settlement window — the same standard it applies to every rail.

Canonical intent

iso 20022 → one record

The native RTP instruction is normalized to a single canonical intent and digest, so it is verified with the same logic as every other rail rather than a bespoke control.

Pre-settlement verdict

released · held

Identity, authority, and signature are checked before release. A suspect payment is held while the irrevocable push can still be stopped, not investigated after it lands.

Verified-channel approval

signed liveness

Human approvals run through the app's verified channel with a nonce-bound, signed liveness check — a replayed or synthetic response is treated as synthetic and held.

Quantum-safe attestation

composite ml-dsa-65

Every intent is signed with post-quantum ML-DSA-65 and sealed to a tamper-evident record, so the decision is independently verifiable and safe against harvest-now-decrypt-later.

How banks deploy RTP verification
FAQ

RTP fraud prevention — questions, answered.

What is RTP fraud prevention?
RTP fraud prevention is stopping a fraudulent real-time payment before it settles on The Clearing House RTP network, rather than trying to claw it back afterward. Because RTP is instant, 24/7, and irrevocable, a payment that settles is gone. RankShield Financial normalizes each RTP instruction into a canonical intent, verifies the payer, payee, amount, and purpose, confirms a human or authorized agent approved it, and returns a released or held verdict before the payment leaves. Fraud is caught while the money is still stoppable, not investigated after it has landed.
Why does RTP irreversibility make pre-settlement verification necessary?
RTP credit-push payments settle with finality in seconds and cannot be reversed by the sender. That removes the safety net that ACH reversals and card chargebacks provide, so any control that runs after settlement is too late to protect the funds. The only place a verification can actually prevent loss on RTP is before the payment is released. RankShield Financial does its identity, authority, and signature checks in that pre-settlement window and produces a verdict — released or held — so a suspect payment is stopped while stopping it still means something.
What is RTP and who operates it?
RTP is the Real-Time Payments network operated by The Clearing House, the first new US payments rail in decades. It carries credit-push payments that settle instantly, run 24 hours a day every day of the year, and are irrevocable once sent. Messages are formatted in ISO 20022, the structured financial-messaging standard. Those properties — instant, always-on, final — are exactly what make RTP attractive for legitimate business and exactly why fraud on it has to be intercepted before settlement rather than reversed after.
How does RankShield normalize an RTP payment?
RankShield takes the native ISO 20022 RTP instruction — debtor, creditor, amount, currency, end-to-end identifier — and reduces it to one canonical intent record, the same shape used for every other rail. That canonical record is hashed to a single digest and signed with post-quantum ML-DSA-65. Normalizing to a common intent means RTP is verified with exactly the same released-or-held logic as FedNow, stablecoin, or on-chain payments, so there is one verifiable standard across rails rather than a separate, weaker path for each network.
How does RankShield help against APP and CEO fraud on RTP?
Authorized-push-payment and CEO-impersonation fraud both work by getting a legitimate user to approve a payment to an attacker — and on RTP that push settles instantly. RankShield verifies the intent and the approval before release, so an out-of-pattern payee, an amount outside granted authority, or a missing or synthetic liveness signal causes the payment to be held instead of settled. APP and crypto-rail scam losses were estimated around $10 to 12 billion a year in the 2024 range, an estimate that underlines why the interception has to happen pre-settlement on an irrevocable rail.
Does deepfake liveness work on a live RTP-triggering phone call?
No, and we are explicit about that boundary. RankShield&apos;s liveness and deepfake checks work only inside the app&apos;s own verified channel — a one-time challenge nonce, a signed detector verdict, and media bound to the specific intent. They do not analyze a live carrier or FaceTime call. So if a CEO-impersonation deepfake is used to trigger an RTP payment, the defense is to require approval through the verified channel, where a replayed or synthetic response is treated as suspect, rather than to claim we can inspect the phone call itself.
Is RankShield a payment processor or an RTP participant?
No. RankShield Financial is a verification and attestation layer, not a wallet, custodian, processor, or RTP participant, and it never takes custody of funds. It verifies the intent before your rail settles it and seals a signed, independently verifiable attestation of the decision. Your existing RTP connection still moves the money. This keeps RankShield out of the funds-flow entirely while still letting it stop a fraudulent payment in the pre-settlement window and prove afterward exactly what was authorized.
Is RTP verification quantum-safe?
Yes, by construction. Each RTP intent is signed with composite ML-DSA-65 from NIST FIPS 204, hybrid with a classical signature and crypto-agile, with transport over hybrid post-quantum TLS where available. That protects the integrity of the intent and its attestation against harvest-now-decrypt-later collection today and a future quantum computer. We say quantum-safe by construction, not quantum-proof — a cryptographically-relevant quantum computer does not exist yet, and the honest claim is that the signing is built to the current post-quantum standard.
How fast is verification, and does it fit inside the RTP timeline?
RTP settles in seconds, so verification is designed to run inside the authorization path in the milliseconds before your institution releases the payment, not as a batch job after the fact. The check that matters most on an instant rail is deterministic: is the intent signed, does it bind this exact payer, payee, amount, and purpose, and — for an AI agent — does it fall inside the granted authority. Those are fast cryptographic and policy checks, not a heavy model scoring pass. When a payment is held, the reason is written to the same signed record, so a reviewer can act on a clear verdict rather than a probability, and a legitimate payment that clears is released without adding human latency to every transaction.
What happens when an RTP payment is held?
A hold is a decision, not a black box. When an RTP intent fails verification — a bad or missing signature, a synthetic-media liveness verdict, or an agent payment outside its constitution — RankShield returns a hold rather than a release, and seals a signed attestation recording exactly which check failed and why. Your institution keeps control of the funds and the customer experience: you decide whether to step the payment up for out-of-band confirmation, route it to a reviewer, or decline it. Because the record is independently verifiable, the same evidence supports a customer explanation, an internal audit, and a fraud-monitoring program, and a released payment carries the same proof that it was authorized exactly as instructed.
Verify, then settle

Verify every RTP payment before it settles for good.

RankShield Financial is rolling out pre-settlement verification for real-time payments with design partners. Request access and we'll map it to your RTP flows.

Request accessPre-settlement verification