# Pre-Settlement Payment Verification | RankShield Financial > Pre-settlement payment verification checks the intent of every payment and proves a human or authorized AI agent approved it before it settles. Request access. > > Source: https://rankshieldfinancial.com/pre-settlement-payment-verification/ · RankShield Financial (verifiable pre-settlement payment security) RankShield Network · Financial # Pre-settlement payment verification. RankShield Financial is a verifiable, **pre-settlement payment verification platform**. It reduces each payment to a canonical intent — payer, payee, amount, and purpose — signs it, proves a human or an authorized AI agent approved it, and returns a released, held, or denied verdict before funds settle on an irreversible rail. Request access See how it works released · held · denied ml-dsa-65 signed authorization path, not custody RankShield Network · pre-settlement ledger ● live RTP $48,500 invoice · acct ••42 anchored ✓ AGENT $1,200 ap_7f3 · vendor anchored ✓ WIRE $96,000 “CEO” call · liveness held · deepfake FEDNOW $7,310 payroll · acct ••08 anchored ✓ USDC 500.00 0x9f…c1 → 0x2a…7e anchored ✓ AGENT $9,900 ap_1c8 · over-limit held · authority verified BEFORE settlement ml-dsa-65 · anchored 01 // The pipeline The pipeline ## Sign, verify, seal, anchor — before settlement. Pre-settlement verification is a pipeline, not a score. Each payment intent is signed, checked against the approving identity and any agent authority, resolved to a verdict, and anchored to a tamper-evident record — all before the money is released to an irreversible rail. 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. Walk the full sign → verify → seal → anchor flow 02 // Why pre-settlement Why pre-settlement ## Why do irreversible rails demand verification before release? Because on an irreversible rail there is nothing to claw back. Real-time and tokenized payments — RTP, FedNow, stablecoins, tokenized deposits — settle with finality in seconds. A scammer, a deepfaked executive, or a hijacked AI agent only has to be believed once, and the money is gone. Fraud tools built for card networks score a transaction and often evaluate it after authorization, which assumes a chargeback window that these rails do not have. Pre-settlement verification moves the decision to the only place it can still change the outcome: before the payment is released. RankShield reduces each payment to a canonical intent, signs it, and returns a released, held, or denied verdict at that moment. If the proof of authorization is missing or fails, the payment is held instead of settled — the difference between stopping fraud and documenting it. How intents stay signed and quantum-safe The irreversible wire ### A settled payment that can't be recalled On RTP or FedNow, a released payment is final in seconds. Once it settles, no dispute, reversal, or chargeback exists to recover it — recovery becomes a legal problem, not a payments one. RankShield: the intent is verified and either released or held before it reaches the rail, so the decision is made while it still matters. The missing proof ### An authorization no one can actually check A conventional tool returns a risk score and moves on. When the payment is later disputed, there is a probability, not a record of who approved this exact payment. RankShield: each verdict is a signed attestation binding the exact payer, payee, amount, and purpose — evidence, not an estimate. 03 // The verdict model The verdict model ## What does the released, held, or denied verdict mean? Pre-settlement verification returns a decision, not a score. Every payment intent resolves to exactly one of three states, and each is recorded with a signed reason. | Verdict | What it means | What happens next | | --- | --- | --- | | Released | Signed intent, approving identity, and agent authority all check out. | The payment may settle on its rail. | | Held | A signature, liveness, or authority check is missing or ambiguous. | Paused for review rather than settled. | | Denied | The intent violates an explicit rule and should not proceed. | Stopped, with a signed record of why. | The point of three states rather than a single fraud score is that a held payment is recoverable — it can be reviewed and released or denied — while a settled fraudulent payment is not. 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 wasn't. 04 // Signing and binding Signing and binding ## How is the intent signed and bound to payer, payee, amount, and purpose? Verification is only meaningful if it covers the exact payment. RankShield binds the fields that define it, so the attestation cannot be reused for a different transaction. Each payment is reduced to a canonical record that fixes the rail, payer, payee, amount, and purpose in a fixed order, then signed with composite ML-DSA-65 — the NIST FIPS 204 post-quantum signature — hybridized with a classical signature. The signature covers all of those fields at once. Change the amount, swap the payee, or alter the purpose and the digest changes, so the seal no longer verifies. That is what binds the attestation to this specific payment: it proves that this payer, paying this payee, this amount, for this purpose, was approved by a specific identity — not that some payment, somewhere, was fine. An attestation captured for a $48,500 invoice cannot be replayed against a $96,000 wire, because they produce different digests. How authorized AI agents are bound to a constitution Payer the source identity, bound into the signed record Payee the counterparty — swapping it breaks the seal Amount fixed in minor units; a changed value fails to verify Purpose what the payment is for, bound into the same digest 05 // Agent authority Who — or what — approved it ## How does verification handle a payment approved by an AI agent? Pre-settlement verification treats an authorized AI agent as a first-class signer, not a trusted script. Each agent has a signed identity and a constitution — an explicit set of bounds on what it may approve — and every agent-initiated intent is checked against it before a verdict is returned. The constitution fixes the maximum per-transaction value, the maximum rolling aggregate over a defined window, the allowed counterparties, the allowed purposes, and an expiry after which the authority lapses. It also carries a dead-man’s-switch heartbeat: if the agent goes silent or is hijacked, its payments are refused rather than released, so a captured agent cannot keep spending. An intent that stays inside every bound can be released; one that exceeds any of them is held or denied, with the specific violated rule recorded in the attestation. This is the same released, held, or denied model applied to non-human approvers, so an agent paying a supplier is held to a signed mandate rather than an assumption that it is behaving. Agentic payment security and the agent constitution Per-tx cap a hard ceiling on any single agent-approved payment Aggregate a rolling limit across a window, not just per payment Counterparties only the payees the agent is allowed to pay Heartbeat silent agent → payments refused, not released 06 // Rails covered One intent, six rails ## Which rails does pre-settlement verification cover? Pre-settlement verification covers six rails by normalizing all of them into one canonical intent before signing. RTP and FedNow are ISO 20022 instant bank rails; stablecoin, tokenized deposit, and CBDC are tokenized value; on-chain settlement is EVM-style. Whatever the rail, RankShield reduces the payment to the same fixed-order record — rail, payer, payee, amount, purpose — so the released, held, or denied model applies identically wherever value moves. That matters because the alternative is re-implementing fraud controls separately for each rail and hoping they agree. Here, the intent is verified once, at the authorization step, and the same signed verdict covers an instant bank payment and a tokenized or on-chain settlement alike. As new rails come online, they normalize into the same canonical intent rather than requiring a new gate. The rail is a field in the record, not a separate product. How six rails normalize into one canonical intent | Rail | Shape | | --- | --- | | RTP | ISO 20022 instant, final in seconds | | FedNow | ISO 20022 instant, final in seconds | | Stablecoin | tokenized value, regulated under the GENIUS Act | | Tokenized deposit | bank-issued tokenized value | | CBDC | central-bank digital currency | | On-chain | EVM-style settlement | 07 // Prove it yourself Prove it yourself ## Can you verify the attestation without trusting us? Yes. Anyone can claim a payment was approved — RankShield lets you check it. The intent below is reduced to the same canonical record used in the platform and hashed in your own browser. Sign and attest it, then change a single field and verify: the digest shifts and the match fails, exactly as it would hold a real payment. Nothing here is faked. Where this proof fits in the pipeline Attestation verifier · run it yourself rail payer payee amount (minor units) purpose nonce canonical: rs-fin-intent-v1|rail=RTP|payer=acct-04f2|payee=acct-1180|amount=4850000|purpose=invoice-2261|nonce=e2e-7c19a3 08 // Settlement reconciliation Settlement reconciliation ## How does RankShield reconcile against what actually settled? A gate at the front isn't enough if the rail can be bypassed or the amount changed after release. RankShield checks the verdict against a signed settlement receipt. After a payment is released, an enrolled settlement oracle returns a signed receipt for what settled. RankShield compares that receipt against the attested intent and resolves it to one of three states. Settled_as_attested means the receipt matches the released intent exactly. Divergence means the settled amount or details differ from what was attested — the classic after-release amount change. Unauthorized_settlement means a payment settled with no matching attestation at all, catching a rail that was bypassed entirely. Because the receipt is signed by an enrolled identity, the reconciliation is itself verifiable rather than a trust-me report. This closes the loop between what was authorized and what happened, so verification is a two-sided check, not a one-time gate. | Reconciliation | What it catches | | --- | --- | | settled_as_attested | Receipt matches the released intent. | | divergence | Settled amount or details changed after release. | | unauthorized_settlement | A payment settled with no matching attestation. | 09 // Where it fits Where it fits ## Where does pre-settlement verification sit in your stack? RankShield sits in the authorization path, not the custody path. It is not a wallet, custodian, or payment processor, and it never takes custody of funds. It is a verification and attestation layer that returns a released, held, or denied verdict — and a signed record of why — which your bank, processor, or settlement system enforces on its own rails. Your existing infrastructure moves the money; RankShield proves the payment was meant to happen. Because it normalizes RTP, FedNow, stablecoin, tokenized-deposit, CBDC, and on-chain transfers into one canonical intent, the same verification applies wherever value moves, so you are not re-implementing controls per rail. The output is evidence — signed attestations and reconciliation records — that produces evidence to support compliance, rather than replacing your payment systems. Why RankShield Financial over post-hoc scoring ### Authorization path verdict, not custody RankShield issues a released, held, or denied decision and a signed record of why — it does not hold or move funds. ### Your rails settle enforced by your systems Your bank, processor, or settlement system enforces the verdict on its own rails. RankShield never becomes the money-movement layer. ### Evidence out support compliance Signed attestations and reconciliation records produce evidence to support compliance — not a compliance guarantee. 10 // Verified, not scored Verifiable, not just scored ## How is a verified verdict different from a fraud score? A fraud score is a probability produced by a model; a verified verdict is a cryptographically checkable decision bound to the exact payment. Some fraud platforms do claim pre-settlement timing, so timing alone is not the difference. 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. | Property | Post-hoc fraud score | RankShield verdict | | --- | --- | --- | | Output | A probability | A released, held, or denied decision | | Timing | Often after authorization | Before settlement, while it can still change | | Approver | Assumed from the session | Signed human or authorized agent | | Checkability | Trust the model | Recompute the digest yourself | | Signing | Classical or none | ml-dsa-65, quantum-safe by construction | | After settlement | No reconciliation | Signed settlement-oracle receipt | Why RankShield Financial over post-hoc scoring Final Instant-rail payments (RTP, FedNow) settle with irrevocable finality — no chargeback, no reversal. 2026 Nacha’s expanded fraud-monitoring rules (Phase 2) push detection earlier, toward pre-settlement verification. FIPS 204 ML-DSA, the NIST post-quantum signature standard RankShield signs every intent with. FAQ ## Pre-settlement payment verification — questions, answered. Every question buyers ask before they trust a payment-security platform, answered directly. JAMIE KLONCZ · RANKSHIELD FINANCIAL ONLINE Pick a question on the left, or search above. You will get the direct answer, the way an answer engine would give it. REQUEST ACCESS → Go deeper ## Guides and analysis ### Payee verification: what it is and why it’s standard How payee verification works, why the Fed and Nacha now expect it, and the gap between matching an account and proving a payment was authorized. Read the guide → ### Payee verification vs Positive Pay vs fraud scoring What each payment control checks, what it misses, and which one actually stops an authorized payment to a fraudster. Read the guide → ### Law firm wire fraud: protecting settlement payouts How a spoofed instruction diverts settlement funds from a trust account, where the loss lands, and the verification a malpractice carrier will respect. Read the guide → ### Payroll diversion: the direct deposit change scam Why the employer, not the employee, pays the diverted paycheck, why self-service portals do not stop it, and the verification that does. Read the guide → ### Agentic payment security: verifying what AI agents pay When software starts spending your money: why proving an agent is legitimate is not the same as proving a payment was authorized, and how to close the gap. Read the guide → ### Harvest now, decrypt later: the quantum payment risk Why encrypted payment data harvested today is exposed tomorrow, the 2024 post-quantum standards and migration clock, and what quantum-safe attestation adds. Read the guide → ### Business email compromise for small business How BEC works, the variants a small business actually sees, and the process control that stops it before settlement. Read the guide → ### Why instant payment fraud is final in seconds How fast RTP and FedNow settle, why a settled payment cannot be recalled, and what the 2026 Nacha rules now require. Read the guide → ### How to stop vendor payment fraud when bank details change How the bank-change scam works, why call-back advice fails on instant rails, and how to verify the payee before you pay. Read the guide → 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. Request access How it works ## Frequently asked questions ### What is pre-settlement payment verification? Pre-settlement payment verification confirms a payment is legitimate before money moves on an irreversible rail, rather than scoring it for fraud afterward. RankShield Financial reduces each payment to a canonical intent — payer, payee, amount, and purpose — signs it, verifies that a human or an authorized AI agent approved it, and returns a released, held, or denied verdict before settlement. Because instant and tokenized rails like RTP, FedNow, and stablecoins are final in seconds, verification has to precede release. The decision is sealed to a tamper-evident record so it can be independently checked later. ### What do the released, held, and denied verdicts mean? Every intent resolves to one of three states. Released means the signed intent, the approving identity, and any agent authority all checked out, so the payment may settle. 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. Each verdict is captured with a signed, verifiable attestation of exactly why it was reached, so the outcome is auditable rather than a black-box score. ### How is a payment intent signed and bound? RankShield reduces each payment to a canonical record that fixes the payer, payee, amount, and purpose, then signs that record with composite ML-DSA-65 — the NIST FIPS 204 post-quantum signature — hybridized with a classical signature. The signature binds those exact fields together: change the amount or the payee and the digest changes, so the seal breaks. That binding is what makes the attestation meaningful — it proves this specific payment, not a payment in general, was approved by a specific identity. You can recompute the digest yourself in the verifier below. ### How does settlement reconciliation work? After a payment is released, an enrolled settlement oracle returns a signed receipt that RankShield compares against the attested intent. The comparison resolves to one of three states: settled_as_attested, when the receipt matches the released intent; divergence, when the settled amount or details differ from what was attested; or unauthorized_settlement, when a payment settled without a matching attestation. This closes the loop — it catches a rail that was bypassed and an amount that changed after release, so verification is not just a gate at the front but a check against what actually happened. ### Does RankShield Financial hold or move my money? No. RankShield Financial 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, not in the custody path. It issues a released, held, or denied verdict and a signed record of why, which your bank, processor, or settlement system enforces. Your existing rails move the money; RankShield proves the payment was meant to happen and produces evidence to support compliance. ### Is it quantum-safe? Every intent is signed with post-quantum cryptography — ML-DSA-65 from NIST FIPS 204 — alongside a classical signature in a hybrid, crypto-agile design that can rotate to ML-DSA-87 or SLH-DSA as standards evolve. This protects authorization records against harvest-now-decrypt-later collection today and a future quantum computer. RankShield is quantum-safe by construction, not quantum-proof: a cryptographically-relevant quantum computer does not exist yet, and the signing layer is built to the current standard. ### How does this handle a payment from an AI agent? An AI payment agent is treated as a first-class signer with a signed identity and a constitution — a set of explicit limits on what it may approve. RankShield checks each agent-initiated intent against that constitution: maximum per-transaction value, maximum rolling aggregate over a window, allowed counterparties, allowed purposes, and an expiry. It also checks a dead-man’s-switch heartbeat, so a silent or hijacked agent has its payments refused rather than released. If the intent stays inside the agent’s granted authority the payment can be released; if it exceeds any bound it is held or denied, with the reason recorded. ### Which rails does pre-settlement verification cover? RankShield normalizes six rails into one canonical intent: RTP, FedNow, stablecoin, tokenized deposit, CBDC, and on-chain transfers. RTP and FedNow are ISO 20022 instant rails; on-chain settlement is EVM-style. Because every payment is reduced to the same canonical record before signing, the released, held, or denied verdict model applies identically wherever value moves. You verify intent once, at the authorization step, rather than re-implementing controls separately for each rail. That is what lets a single pre-settlement gate cover instant bank rails and tokenized or on-chain settlement at the same time.