RankShield Network · Financial
Questions, answered.The proof is in the details.RankShield Financial is a verifiable, pre-settlement payment security platform. It reduces each payment to a canonical intent — payer, payee, amount, and purpose — signs it, proves a real human or an authorized AI agent approved it, and returns a released, held, or denied verdict before funds settle on an irreversible rail. It never takes custody.
This is the RankShield Financial FAQ — a pre-settlement payment verification FAQ that answers what the platform is, how the released, held, and denied verdict works, which payment rails it covers, how AI payment agents are governed, how signing stays quantum-safe, and how your data is protected. Every answer is self-contained. Try the verifier below, then read the categories in descending order.
released · held · deniedml-dsa-65 signedauthorization path, not custody
Attestation verifier · run it yourself
canonical: rs-fin-intent-v1|rail=RTP|payer=acct-04f2|payee=acct-1180|amount=4850000|purpose=invoice-2261|nonce=e2e-7c19a3
01 // The basics
The basics
What is RankShield Financial, and what does it not do?
What is RankShield Financial?
RankShield Financial is a verifiable, pre-settlement payment security platform. It reduces each payment to a canonical intent — payer, payee, amount, and purpose — signs it, proves a real human or an authorized AI agent approved it, and returns a released, held, or denied verdict before the money settles on an irreversible rail. It is not a wallet, custodian, or payment processor and never takes custody of funds. It sits in the authorization path as a verification and attestation layer, producing signed evidence that your bank, processor, or settlement system enforces on its own rails.
How is pre-settlement verification different from post-hoc fraud scoring?
Post-hoc fraud tools score a transaction, often after authorization, assuming a chargeback or reversal window exists to claw money back. Instant and tokenized rails do not have that window — a released RTP or stablecoin payment is final in seconds. Pre-settlement verification moves the decision to the only place it can still change the outcome: before the payment is released. Instead of a probability, RankShield returns a released, held, or denied verdict with a signed record of exactly why. The difference is stopping a fraudulent payment versus documenting one after the money is gone. See our full explanation of pre-settlement payment verification.
What does RankShield Financial not do?
It does not hold or move your money. RankShield Financial is not a wallet, custodian, or payment processor, and it never takes custody of funds. It does not replace your payment rails or your settlement systems — it sits in the authorization path alongside them and returns a verdict plus a signed record of why. It does not promise to make you compliant; it produces evidence to support compliance. It also cannot analyze a live carrier phone call — liveness and deepfake checks work only inside the platform own verified channel, never on a standard FaceTime or phone call.
Does RankShield Financial ever take custody of my funds?
No. Custody is explicitly out of scope. RankShield sits in the authorization path, not the custody path. It issues a released, held, or denied decision and a signed attestation of the reasoning, and your existing bank, processor, or settlement system enforces that decision on its own rails. Your infrastructure moves the money; RankShield proves the payment was meant to happen. This separation is deliberate: by never becoming the money-movement layer, RankShield stays a neutral verifier whose evidence can be independently checked rather than a party with its own stake in the transfer.
Is RankShield Financial available today?
The backend MVP is built and proven, and the platform is rolling out with design partners. There is no live payment-rail integration yet, so the right next step is to request access rather than to buy or download anything. During the design-partner phase we map the verification and attestation layer to a partner settlement flow, in observe mode first, so you can see released, held, and denied verdicts against real intent shapes before anything gates a live payment. RankShield Financial is one pillar of the broader RankShield Network trust fabric.
Who is RankShield Financial for?
It is built for the institutions that move value on instant and tokenized rails: banks, fintechs and payment service providers, stablecoin issuers, crypto custodians, corporate treasury teams, and marketplaces or platforms disbursing at scale. Anyone releasing payments onto a rail with irreversible finality — or delegating payments to AI agents — faces the same problem: the decision has to be made and proven before settlement. RankShield gives each of them the same canonical intent, verdict model, and signed evidence, so controls are not re-implemented per rail or per team.
02 // How verification works
How verification works
How does pre-settlement verification actually work?
What is a canonical intent?
A canonical intent is the reduced, fixed-order record of the fields that define a payment: the rail, payer, payee, amount, and purpose. RankShield takes a payment request and normalizes it into this canonical shape so the same structure applies whether the value moves over RTP, FedNow, a stablecoin, a tokenized deposit, a CBDC, or on-chain. That canonical record is what gets signed. Because the fields are fixed in a defined order, the record has one deterministic digest — change any field and the digest changes — which is what makes the later attestation bind to this exact payment rather than to a payment in general.
What do the released, held, and denied verdicts mean?
Every intent resolves to exactly one of three states. Released means the signed intent, the approving identity, and any agent authority all checked out, so the payment may settle on its rail. Held means something is missing or ambiguous — a failed signature, an out-of-authority agent, a liveness flag — so the payment is paused for review rather than settled. Denied means the intent violated an explicit rule and should not proceed. RankShield defaults to holding when proof is absent, so the burden is on the payment to demonstrate it was authorized, not on the victim to demonstrate it was not.
What is the sign, verify, seal, anchor pipeline?
Pre-settlement verification is a pipeline, not a single score. First the canonical intent is signed with the payment identity. Then it is verified against the approving human or agent authority to reach a released, held, or denied verdict. Then the verdict and its reasoning are sealed into a tamper-evident record, and that record is anchored to the RankShield Network so it can be independently checked later. Each stage happens before the money is released to an irreversible rail. Walk the full flow on our how it works page and see where signed evidence enters the pipeline.
Can I verify an attestation without trusting RankShield?
Yes, and that is the point. Anyone can claim a payment was approved; RankShield lets you check it yourself. Each attestation covers a canonical intent whose digest you can recompute independently. Change a single field — the amount, the payee — and the digest shifts, so the seal no longer matches, exactly as it would hold a real payment. The verifier on this page runs entirely in your own browser: nothing is faked. This is why we describe our output as verifiable evidence rather than a trust-me report. Our verifiable attestation page goes deeper on independent checking.
How does settlement-oracle reconciliation close the loop?
A gate at the front is not enough if a rail can be bypassed or an amount changed after release. After a payment is released, an enrolled settlement oracle returns a signed receipt for what actually settled, and RankShield compares it against the attested intent. The result is one of three states: settled_as_attested when the receipt matches, divergence when the settled amount or details differ from what was attested, or unauthorized_settlement when a payment settled with no matching attestation at all. Because the receipt is signed by an enrolled identity, the reconciliation is itself verifiable — a two-sided check, not a one-time gate.
Why hold a payment instead of just flagging it?
Because a held payment is recoverable and a settled fraudulent payment is not. Flagging a transaction that has already settled on an irreversible rail turns fraud into a legal-recovery problem rather than a payments one. By resolving to a held state before release, RankShield keeps the payment in a reviewable position: it can be examined and then released or denied with a signed reason. Three explicit states — released, held, denied — are more useful than a single risk number precisely because the held state is a place where the outcome can still change.
03 // Payment rails
Payment rails
Which payment rails does RankShield verify, and why?
What does rail-agnostic mean here?
Rail-agnostic means RankShield normalizes six different payment rails — RTP, FedNow, stablecoin, tokenized deposit, CBDC, and on-chain — into one canonical intent, so the same verification, verdict model, and signed evidence apply wherever value moves. You are not re-implementing controls per rail. RTP and FedNow are ISO 20022 instant-payment rails; on-chain settlement is EVM-style. Underneath they differ in message format and finality, but once each is reduced to a canonical intent of rail, payer, payee, amount, and purpose, they verify the same way. Our payment rails overview shows how each rail maps into the canonical shape.
Which payment rails does RankShield support?
Six: RTP and FedNow (the US instant rails, both ISO 20022), stablecoins, tokenized deposits, CBDCs, and on-chain transfers (EVM-style). Each is normalized into one canonical intent so verification is consistent across all of them. The common thread is finality — these are the rails where a released payment is hard or impossible to reverse, which is exactly why the decision has to be made and proven before settlement. See the dedicated pages on RTP fraud prevention, FedNow fraud prevention, stablecoin payment security, tokenized deposit security, and on-chain settlement verification.
Why does rail finality make pre-settlement verification necessary?
On an irreversible rail there is nothing to claw back. Real-time and tokenized payments settle with finality in seconds, so once a payment is released it is effectively gone — no dispute, reversal, or chargeback exists to recover it. A scammer, a deepfaked executive, or a hijacked AI agent only has to be believed once. Fraud tools built for card networks assume a chargeback window these rails do not have. Pre-settlement verification is the response: it moves the released, held, or denied decision to before the payment reaches the rail, while the outcome can still change.
How does RankShield handle on-chain versus instant-rail payments?
Both are reduced to the same canonical intent, but their native details differ. RTP and FedNow carry ISO 20022 messaging and settle through bank infrastructure; on-chain transfers are EVM-style and settle on a public ledger. RankShield captures the rail-specific identifiers inside the canonical record so the attestation reflects the real payment, then applies one verdict model across all of them. After release, settlement-oracle reconciliation compares a signed receipt from the relevant rail against the attested intent, catching divergence or an unauthorized settlement regardless of whether the value moved over an instant rail or on-chain.
Does RankShield connect directly to the payment networks?
Not yet. The platform is rolling out with design partners and there is no live rail integration in production today. RankShield is designed to sit in the authorization path and hand a released, held, or denied verdict, plus a signed record, to the system that operates the rail — it does not itself become the rail or move the money. During the design-partner phase we map the verification layer to a partner settlement flow so verdicts can be observed against real intent shapes. Request access to discuss which of the six rails matters most for your flow.
04 // AI payment agents
AI payment agents
How are AI payment agents governed?
How does RankShield govern AI payment agents?
Each AI payment agent gets a signed identity and a constitution — an explicit, signed set of limits that its payments are checked against before release. The constitution defines a maximum per transaction, a maximum rolling aggregate over a window, the counterparties the agent is allowed to pay, the purposes it is allowed to pay for, and an expiry after which its authority lapses. When an agent submits a payment intent, RankShield verifies both the signature and that the intent falls inside the constitution. Anything outside those bounds is held or denied. Our agentic payment security page details how each rule is enforced.
What limits can an agent constitution enforce?
A constitution can bound an agent by maximum per-transaction amount, maximum rolling aggregate spend within a defined window, an allow-list of counterparties it may pay, an allow-list of purposes it may pay for, and a valid_until expiry. A payment that exceeds the per-transaction cap, breaches the rolling aggregate, targets a counterparty or purpose outside the allow-list, or arrives after expiry does not release. Because the constitution is signed, the limits themselves are tamper-evident — an agent cannot quietly grant itself more authority. See how autonomous spending stays bounded on the AI agent payment risks page.
What is the dead-man heartbeat?
The dead-man switch is a heartbeat requirement: an authorized AI agent must keep signaling that it is healthy and under control. If the agent goes silent — because it crashed, was cut off, or was compromised and isolated — its heartbeat stops, and RankShield refuses its payments rather than continuing to trust an agent nobody is watching. This inverts the usual failure mode. Instead of a silent, hijacked agent continuing to move money, silence itself becomes a stop condition. Combined with the signed constitution and expiry, it keeps agent authority tightly scoped in time as well as amount.
How does RankShield handle prompt injection against a payment agent?
The defense is that the constitution is enforced outside the agent, not inside its reasoning. Prompt injection might convince an AI agent to try to pay an attacker, but the resulting payment intent still has to pass RankShield against the agent signed constitution. If the attacker counterparty is not on the allow-list, the purpose is not permitted, the amount exceeds the cap, the rolling aggregate is breached, or the authority has expired, the payment is held or denied regardless of what the agent was talked into. Verification does not depend on the agent having resisted the manipulation.
Are AI agent keys quantum-safe too?
Yes. Agent identities are signed with the same post-quantum, crypto-agile approach used across the platform. Each agent key is built to rotate as standards evolve, so an agent signed identity — and therefore its constitution and every payment it authorizes — carries the same quantum-safe-by-construction protection as a human-approved intent. This matters because agents may operate for long-lived windows, and their authorization records should resist harvest-now-decrypt-later collection just as human authorizations do. The quantum-safe payments page covers the signing scheme in full.
05 // Quantum safety
Quantum safety
How is signing kept quantum-safe?
How is RankShield Financial quantum-safe?
Every payment intent is signed with composite ML-DSA-65 — the NIST FIPS 204 post-quantum signature — hybridized with a classical signature. The design is crypto-agile, meaning it can rotate the algorithm as standards evolve, for example from ML-DSA-65 to ML-DSA-87 or to SLH-DSA. Where available, transport uses hybrid post-quantum TLS with ML-KEM (NIST FIPS 203). The point is that authorization records signed today remain trustworthy against a future quantum computer, not just against classical attackers. Read the full signing scheme on the quantum-safe payments page.
What is ML-DSA-65 and FIPS 204?
ML-DSA is the Module-Lattice Digital Signature Algorithm, standardized by NIST as FIPS 204 in August 2024. ML-DSA-65 is a specific parameter set of that standard. RankShield uses composite ML-DSA-65: the post-quantum signature is combined with a classical signature so a record is valid only if both hold. FIPS 204 is one of three post-quantum standards NIST finalized — alongside FIPS 203 (ML-KEM, for key encapsulation) and FIPS 205 (SLH-DSA, a hash-based signature). Signing every intent to this standard is what lets us call the platform quantum-safe by construction.
Why hybrid classical plus post-quantum instead of post-quantum alone?
Hybrid signing means each record carries both a classical signature and a post-quantum one, and is accepted only if both verify. This hedges against two risks at once. If an as-yet-undiscovered weakness were found in the newer post-quantum scheme, the classical signature still protects the record; and if a future quantum computer breaks the classical scheme, the post-quantum signature still holds. It is a belt-and-suspenders posture appropriate for authorization records that need to remain trustworthy for years. Because the design is crypto-agile, either half can be rotated to a stronger algorithm without re-architecting the system.
What does quantum-safe by construction mean, and why not quantum-proof?
Quantum-safe by construction means the signing layer is built to the current NIST post-quantum standard from the start, rather than bolted on later. We deliberately do not say quantum-proof. No serious cryptographer claims a system is proof against all future attacks, and a cryptographically-relevant quantum computer does not exist yet, so the honest claim is that the platform is built to the best available standard and can rotate as those standards advance. Crypto-agility is what backs the claim: when the standard moves, the platform moves with it rather than being stuck.
What is harvest-now-decrypt-later, and why does it matter today?
Harvest-now-decrypt-later is the threat that an adversary records encrypted or signed data today and stores it, waiting for a future quantum computer capable of breaking classical cryptography to decrypt or forge it retroactively. It matters now because the data being harvested is being created now — and payment authorization records may need to stay trustworthy for years. Signing intents with post-quantum cryptography today protects them against that future capability. Our harvest-now-decrypt-later page explains why the clock started before any quantum computer arrives.
Does a quantum computer capable of breaking today cryptography already exist?
No. A cryptographically-relevant quantum computer — one able to break the classical cryptography in wide use — does not exist yet. The reason to move now is preparation, not a live break: the harvest-now-decrypt-later threat means data created today can be targeted later, and standards bodies are already planning transitions. NIST IR 8547 is a draft that proposes deprecating RSA and elliptic-curve cryptography after 2030 and disallowing them after 2035; it is a proposal, not a hard law. Building on FIPS 204 now means being ready ahead of that timeline rather than scrambling to catch up.
06 // Data protection
Data protection & security
How is my data protected?
Does RankShield store account numbers or PII?
No. The ledger stores commitments, not account numbers, so there is no PII in the record. Account references are HMAC-keyed and de-identified under a secret pepper, which is preimage-resistant, then stored as nonce-bound commitments. What is retained is a cryptographic commitment to an account, openable only with the key — not the account itself. This keeps the tamper-evident record verifiable while avoiding the risk and compliance burden of holding raw financial identifiers. Our data protection page walks through exactly what is and is not stored.
How do commitments make the ledger unlinkable?
Because each commitment is nonce-bound, the same account looks different on every transaction. An HMAC-keyed reference under a secret pepper is combined with a per-transaction nonce, so an observer sees a fresh, unrelated-looking commitment each time even for a repeat counterparty. Only a holder of the key can open a commitment to confirm which account it represents. This unlinkability means the record can be published as tamper-evident evidence without leaking a payment graph — you cannot cluster a party activity by scanning commitments. It is a property of salted commitments, an established privacy primitive.
Are these zero-knowledge proofs?
Not full zk-SNARK proofs, and we are careful not to overstate it. The commitments RankShield uses are salted commitments — a zero-knowledge primitive that provides preimage resistance and unlinkability — rather than complete succinct zero-knowledge proof systems. They let the ledger hold a verifiable commitment to an account without revealing the account, which is the property that matters for privacy here. Describing them accurately as salted commitments rather than zk-SNARKs is part of the platform honesty doctrine: claim the primitive that is actually implemented, not a stronger one.
Where do the signing keys live?
Signing keys live in a hardware security module (HSM), so the private key material is not exposed in application memory. Beyond that, releasing a payment requires an M-of-N quorum — several key-holders must agree, and no single key can authorize a release on its own. This removes the single point of failure where one compromised key would be enough to sign off a fraudulent payment. It also means the release decision is distributed, which is consistent with RankShield role as a verifier of authorization rather than a custodian of funds.
What is the M-of-N quorum for?
M-of-N means that out of N authorized key-holders, at least M must sign for a release to proceed. Its job is to eliminate the single-key risk: an attacker who compromises one key still cannot release a payment, because the threshold is not met. This distributes trust across multiple holders and makes an internal or external compromise far harder to weaponize into an unauthorized release. Combined with HSM-resident keys and the held-by-default verdict model, it means releasing a payment is a deliberate, multi-party act — not something a single credential can force.
Can an observer link my payments across transactions?
No. That is the specific property nonce-bound commitments provide. Because the same account is committed with a fresh nonce each time, two payments involving the same party do not produce the same value on the ledger, so an outside observer cannot correlate them. The commitment is openable only with the key, so linkage is available to an authorized holder and no one else. This lets RankShield keep a tamper-evident, independently checkable record while preventing that record from becoming a map of who pays whom.
07 // Compliance & getting started
Compliance & getting started
What about compliance, and how do I get started?
Does RankShield Financial make me compliant?
No — and we are deliberate about this wording. RankShield does not make you compliant; it produces evidence to support compliance. The platform outputs signed attestations of who approved each payment and why, plus settlement-oracle reconciliation records comparing what was authorized to what settled. That evidence is verifiable and tamper-evident, which supports audit and regulatory needs, but the compliance obligation and its interpretation remain yours. Framing it as evidence rather than a guarantee is part of the honesty doctrine. Our compliance page details what the evidence covers.
How do the Nacha 2026 rules relate to this?
Nacha expanded its fraud-monitoring rules — Phase 2, in 2026 — in a direction that pushes fraud detection earlier, toward pre-settlement verification on the ACH and instant-payment network. That is the same shift RankShield is built around: making and proving the decision before a payment settles, rather than scoring it afterward. We attribute this as a regulatory direction from Nacha, not a claim that using RankShield satisfies the rule for you. It signals that the industry timing is moving toward pre-settlement checks, which is where the released, held, or denied model lives.
What is the GENIUS Act and how does it fit?
The GENIUS Act is US stablecoin legislation from 2025 that pushes verification onto regulated stablecoins. Because stablecoins are one of the six rails RankShield normalizes into a canonical intent, the platform pre-settlement verification and signed evidence apply directly to stablecoin payments. We cite the GENIUS Act as regulatory context indicating that verification on regulated stablecoins is a growing expectation — not as a claim that RankShield discharges any specific obligation under it. See how stablecoin payments are verified on our stablecoin payment security page.
How does RankShield differentiate from existing fraud tools?
Some tools claim pre-settlement timing, so timing alone is not the differentiator. RankShield distinguishes on verifiable cryptographic evidence that is identity-bound and quantum-safe: each verdict is a signed attestation binding the exact payer, payee, amount, and purpose, checkable by anyone, and signed with post-quantum cryptography. We are not aware of another platform that combines pre-settlement verification, identity-bound cryptographic attestation, agentic spend governance, and quantum-safe signing in one layer. Rather than a risk score you have to trust, you get evidence you can independently check. Our why RankShield Financial page lays out the comparison.
How do I get started with RankShield Financial?
Request access. RankShield Financial is rolling out with design partners and does not yet have a self-serve product or live rail integration, so there is nothing to buy or download today. In the design-partner phase we map the verification and attestation layer to your settlement flow, typically starting in observe mode so you can see released, held, and denied verdicts against your real intent shapes before anything gates a live payment. From there we scope which of the six rails and which agent-governance controls matter most for you.
What evidence does RankShield actually produce?
Two kinds. First, a signed pre-settlement attestation for every payment: the canonical intent, the released, held, or denied verdict, and the reasoning, sealed to a tamper-evident record and anchored on the RankShield Network. Second, settlement reconciliation records that compare a signed oracle receipt against the attested intent, resolving to settled_as_attested, divergence, or unauthorized_settlement. Both are independently verifiable rather than trust-me reports. Together they document who approved a payment, why, and whether what settled matched what was authorized — evidence to support compliance and audit, produced as a byproduct of verification.
Verify, then settle
See your payments verified before they settle.
RankShield Financial is rolling out with design partners on instant and tokenized rails. Request access and we’ll map it to your settlement flow.