Request access
RankShield Network · Financial · Solutions

Payment fraud preventionfor banks on instant rails.RankShield Financial is a verifiable, pre-settlement payment security platform for banks and credit unions. It verifies the intent behind every RTP and FedNow payment, proves a real human or an authorized agent approved it, and releases or holds the payment before it settles — without ever taking custody of funds.

ml-dsa-65 signedno custody of fundsrtp · fednow
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
01 // Instant-rail exposure
Why now

Why do instant rails change the fraud problem for banks?

Instant rails change the fraud problem because RTP and FedNow settle with finality in seconds, so there is no meaningful window to claw a payment back once it has moved. Traditional fraud programs were tuned to batch ACH and card networks, where reviews, holds, and reversals bought hours or days. On instant rails, an authorized-push-payment scam, a business-email-compromise wire, or a hijacked payment agent can push irreversible value before any after-the-fact review fires. Credit unions feel this acutely: leaner fraud teams face the same real-time payment fraud as the largest banks, with less room to build detection in-house. Nacha expanded its fraud-monitoring rules in a 2026 phase precisely to push detection earlier, toward pre-settlement. The structural fix is to verify the intent of a payment before it settles, inside the bank’s own authorization path, rather than to notice an anomaly after the money is gone.

RTP fraud prevention in depth
Seconds
RTP and FedNow settle with finality in seconds — no clawback window once value moves.
APP scams
Authorized-push-payment and CEO-fraud losses were estimated around $10–12B a year in the 2024 range.
Earlier
Nacha’s 2026 phase pushes fraud monitoring toward pre-settlement verification.
02 // In the authorization path
Where verification sits

How does pre-settlement verification sit in the bank’s authorization path?

Pre-settlement verification sits as a check inside the bank’s own authorization path, between the payment request and settlement, without taking custody of funds. When an instant payment is initiated, RankShield Financial reduces it to a canonical intent record — payer, payee, amount, purpose — signs it, confirms a real human or an authorized agent approved it, and returns a released, held, or denied verdict before the payment reaches the rail. Released payments continue to settle on your existing RTP or FedNow flow untouched; held payments route back to a human or a stricter quorum; denied payments never leave. RankShield is not a processor and never moves the money — your core and rails still do that. The live ledger here shows intents arriving and resolving to a verdict pre-settlement, which is exactly the decision point RankShield inserts into your flow.

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
03 // Sign, verify, seal, anchor
The verification pipeline

What happens between authorization and settlement?

Between authorization and settlement, each payment intent moves through a fixed pipeline that resolves before value can move. The intent is reduced to a canonical record and signed with post-quantum ML-DSA-65. Its signature, the approver’s identity, any liveness challenge, and — for agent payments — the agent’s granted authority are verified against what was actually approved. Only then is the payment released, held, or denied. The verdict and its reasons are sealed to a tamper-evident record and anchored on the RankShield Network, so the decision is independently verifiable after the fact. Nothing in this pipeline holds member balances; it holds commitments and verdicts. That means your fraud, compliance, and audit teams gain a signed account of why every instant payment was allowed or stopped, produced at the moment of decision rather than reconstructed from logs later.

01

Sign

The payment intent is reduced to a canonical record and signed with post-quantum ML-DSA-65.

02

Verify

Signature, identity, liveness and agent authority are checked against the granted mandate.

03

Seal

A release or hold decision is produced with a signed, independently verifiable attestation.

04

Anchor

The decision is sealed to a tamper-evident record on the RankShield Network — before settlement.

04 // Protecting the customer
APP and CEO fraud

How does this protect instant-rail customers from APP and CEO fraud?

It protects customers by verifying the intent and the human behind a payment before an irreversible instant transfer settles, which is where authorized-push-payment and CEO-fraud scams do their damage. In these scams the customer is manipulated into approving a real payment to a fraudster, so classic account-takeover defenses miss it entirely. RankShield Financial checks that the payment intent matches what was actually approved and, where a bank enrolls it, that a live human is present through a signed liveness challenge in the bank’s own app channel. A payment that fails these checks is held rather than released, giving the institution a pre-settlement moment to intervene. This is a structural gate at the authorization step, not a fraud score reviewed after the money is already gone.

The coached victim

A member is talked into an urgent instant payment

A scammer impersonating the bank calls a credit-union member and coaches them into sending an RTP payment to a mule account, framed as fraud protection so the member approves it themselves.

RankShield: RankShield verifies intent pre-settlement and, in the bank’s own app channel, can require a signed liveness challenge; when the intent or presence check fails, the payment is held before it settles rather than clawed back after.
Held, not chased
A failed intent or liveness check holds the payment before finality — the safe default is to stop, not to pay.
05 // Data stays private
What we never hold

How does customer and account data stay private?

Customer and account data stays private because RankShield Financial verifies payments without ever storing account numbers or PII. Account references are HMAC-keyed and de-identified under a secret pepper that is preimage-resistant, then stored as nonce-bound commitments, so the same account looks different on every transaction and is unlinkable to an outside observer, openable only with the key. The ledger holds commitments and verdicts, not account details. Signing keys live in an HSM, and releasing any payment requires an M-of-N quorum, so no single key — and no single insider — can move value. Being honest about the primitive: these are salted commitments, a zero-knowledge building block, not full zk-SNARK proofs. For a bank, this means participating in verifiable pre-settlement checks without handing a third party the member data it would otherwise have to protect.

No PII stored

commitments, not accounts

Account references become de-identified, nonce-bound commitments. The ledger holds commitments and verdicts, so there is no account number to breach.

Unlinkable

different every transaction

The same account looks different on every payment, so an observer cannot link a member’s activity across transactions. Only the key can open the commitment.

HSM keys

M-of-N quorum

Signing keys live in a hardware security module, and releasing a payment needs an M-of-N quorum — no single key or insider moves value alone.

Quantum-safe

ml-dsa-65 · crypto-agile

Intents are signed with composite ML-DSA-65 under NIST FIPS 204, crypto-agile to rotate schemes. Quantum-safe by construction, not quantum-proof.

06 // Evidence for exams
Signed evidence

What evidence does this produce for Nacha 2026 programs and exams?

It produces a signed, tamper-evident record of every released, held, or denied verdict, anchored on the RankShield Network, that a bank can present to examiners as evidence of pre-settlement fraud monitoring. To be precise: RankShield produces evidence to support compliance — it does not make you compliant, and the determination stays with your program. Nacha’s expanded 2026 fraud-monitoring rules push detection earlier toward pre-settlement, and this layer sits at exactly that point, capturing why each instant payment was allowed or stopped at the moment of decision. Because each record is cryptographically signed and independently verifiable, your audit team is not asking an examiner to trust an internal log; the artifact can be checked on its own. That turns a fraud-monitoring narrative into demonstrable, per-payment proof.

CapabilityLog-and-review approachRankShield-verified bank
TimingReviewed after settlementVerdict before settlement
Approver identityAssumed from sessionSigned human or authorized agent
Deepfake defenseNone in-channelSigned liveness in the bank’s app
Data heldAccount numbers and PIIDe-identified commitments, no PII
SigningClassical or noneml-dsa-65, quantum-safe by construction
Exam evidenceInternal logs to trustSigned, independently verifiable record
07 // Why verifiable wins
Verifiable, not just scored

How is this different from a fraud score on the payment?

It is different because a fraud score is a probability produced after or alongside the payment, while RankShield Financial produces a cryptographically verifiable, identity-bound verdict before settlement. Some fraud platforms do claim pre-settlement timing, so timing alone is not the whole story. What we are not aware of another platform combining is verifiable cryptographic proof, identity binding of the actual approver, in-channel liveness, and quantum-safe signing in one pre-settlement gate. A score tells you a payment looked risky; a signed verdict lets an examiner or a partner bank independently confirm that this specific intent was approved by this specific principal and released or held for a stated reason. For a bank, that shifts the conversation from a model’s opinion to demonstrable, per-payment evidence you can hand to anyone who needs to verify it.

Why choose RankShield Financial
FAQ

Payment fraud prevention for banks — questions, answered.

What is payment fraud prevention for banks with RankShield Financial?
It is a pre-settlement verification layer that a bank or credit union places inside its own authorization path for instant payments. Before an RTP or FedNow payment settles, RankShield Financial reduces the intent to a canonical record, confirms it is signed by a real human or an authorized agent, and returns a released, held, or denied verdict. It never takes custody of funds. The verdict and its reasons are sealed to a tamper-evident record, so the bank keeps signed evidence of exactly why each instant payment was allowed or stopped.
How does this help with credit union real-time payment fraud?
Credit unions face the same instant-rail exposure as large banks but with leaner fraud teams, so real-time payment fraud is especially hard to catch after value moves. RankShield Financial verifies intent before settlement, so an authorized-push-payment scam or a hijacked agent is held at the authorization step rather than reviewed after the money is irreversibly gone. Because the verification is structural and cryptographic, a small institution gets the same pre-settlement standard as a large one without building it in-house.
Does RankShield make our bank compliant with Nacha 2026?
No. RankShield Financial produces evidence to support compliance; it does not make you compliant. Nacha expanded its fraud-monitoring rules in a 2026 phase to push detection earlier, toward pre-settlement verification. RankShield sits at that pre-settlement point and seals a signed, tamper-evident record of each released, held, or denied verdict. That gives your compliance and audit teams verifiable artifacts to show examiners how instant payments were screened, but the compliance determination and program remain yours.
Do you take custody of our members’ or customers’ funds?
Never. RankShield Financial is a verification and attestation layer, not a wallet, custodian, or payment processor. It sits in the authorization path and returns a verdict; your existing rails and core still move the money. No account balances pass through RankShield, and account references are stored only as de-identified commitments, not account numbers, so there is nothing there to custody or expose.
How does deepfake liveness work in our app channel?
Liveness runs only inside your bank’s own verified app channel, never on a live carrier or FaceTime call. When a high-risk payment needs a human present, RankShield issues a one-time challenge nonce, a detector returns a cryptographically signed verdict from an enrolled identity, and the media is bound one-to-one to that specific payment intent. A replayed clip is treated as synthetic and the payment is held. This closes the gap where a scammer coaches a victim, but only within the channel your bank controls.
What signing protects the payment records?
Every intent is signed with composite ML-DSA-65 from NIST FIPS 204, hybridized with a classical signature, in a crypto-agile design that can rotate to stronger schemes such as ML-DSA-87 or SLH-DSA. Transport uses hybrid post-quantum TLS where available. This is quantum-safe by construction, not quantum-proof: a cryptographically relevant quantum computer does not exist yet, but harvest-now-decrypt-later collection is a present risk, so the signing layer is built to the current post-quantum standard today.
How is our data kept private inside the verification?
Account references are HMAC-keyed and de-identified under a secret pepper, then stored as nonce-bound commitments, so the same account looks different on every transaction and is unlinkable to an observer. The ledger stores commitments, not account numbers, so it holds no PII. Signing keys live in an HSM, and releasing a payment requires an M-of-N quorum, so no single key can move value. These are salted commitments, a zero-knowledge primitive, not full zk-SNARK proofs.
Is this available to deploy today?
RankShield Financial’s backend is built and proven, and the product is rolling out with design partners; there is no live rail integration yet. So the honest answer is that banks and credit unions can request access to join the design-partner program rather than buy an off-the-shelf integration. During that engagement we map the released, held, and denied model to your instant-rail authorization path and to the evidence your exams require.
Verify, then settle

Verify instant payments before they settle.

RankShield Financial is rolling out pre-settlement verification with design-partner banks and credit unions on RTP and FedNow. Request access and we’ll map the released, held, and denied model to your authorization path.

Request accessPre-settlement verification