High-Risk AP Control

Require mutual authorization before payments move.

CAST adds a mutual authorization step before payments are released. Vendors confirm exact details via a secure link. This creates a clear, verifiable record for both sides.

Request access → Read the architecture
POST /v1/work-orders/wo_8fa2/confirm 
# Vendor confirms via passkey — the bilateral pivot
{
  "event":        "bilateral.confirmed",
  "work_order":   "wo_8fa2c1",
  "payload_hash": "3a9f…e21b",
  "signature": {
    "method": "webauthn-p256",
    "bound_to": "payload_hash",
    "signer": "agent_riverdale"
  },
  "policy_version": "POL-v4.2",
  "lineage_hash": "7c0d…b48a"
}
→ Posting blocked until signature verifies.
→ Posting carries lineage to this event. Forever.
The unilateral model costs
$2.9B
Annual U.S. BEC losses
3 days → 30 min
Reconciliation, post-deployment
1 of 2
Parties confirm terms today
0
Proofs the output is real
The root cause

Today’s AP process is one-sided by design.

Your team approves an invoice internally. The vendor only learns the final details when — or if — the money arrives.

This gap creates risk because the vendor has no formal role to confirm details before funds leave. Attackers can change bank details or submit fake invoices without the real vendor knowing. Rush payments and high-value transfers increase exposure — urgency leads teams to skip checks exactly when the stakes are highest.

Mutual Authorization

One party proposes. Both parties confirm. Policy governs what happens next.

The AP instantiation — Confirm & Pay — walks one invoice through the loop. Steps 1–5 are the entire prototype. The cryptographic chain is the product; the screens are its packaging.

01 · PROPOSE

High-risk payment identified

Your rules flag a payment that needs mutual authorization (first vendor, bank change, high value, rush, etc.).

02 · SEND

Secure link sent to vendor

The vendor receives a simple browser link showing the amount, invoice, date, and bank details. No login or app required.

03 · AUTHORIZE

Vendor provides mutual authorization

The vendor reviews and authorizes the payment details (or requests a change / disputes). This creates the binding authorization record.

The pivot
04 · RELEASE

Payment proceeds with proof

Only after mutual authorization does the payment release. A clear, verifiable record is created automatically.

Five primitives

Everything else is a projection of these five objects.

Append-only by design. Mutual authorization is enforced before any high-risk posting. This creates verifiable proof without added complexity.

primitive.event

Event

An immutable record of something that happened. Proposed events come from one side; mutual authorization events require confirmation from both parties.

Constraint: Append-only. No updates. No deletes. Ever.
primitive.policy

Policy Version

A versioned, immutable rule set. Pinned to every event at the time it is processed. It governs triggers, auto-approve conditions, and how exceptions are handled.

Constraint: Policies cannot be changed retroactively. Earlier events keep the policy version that applied when they occurred.
primitive.work_order

Work Order

The container that holds the full context and decisions for a payment. It tracks three parallel states (Authorization, Control, and Settlement) without collapsing them.

Constraint: Every decision is recorded as an immutable event.
primitive.posting

Posting

A journal-ready ledger entry created only after mutual authorization is complete. It carries the full history back to the original event.

Constraint: A posting cannot exist without a completed mutual authorization record.
primitive.case

Case

A governed exception (dispute, non-response, budget breach, policy gap, etc.). Resolution events are added, but prior events are never changed or deleted.

Constraint: The record of the exception is permanent.
lineage()

The proof is the asset

Every posting is traceable back through the events, decisions, and policy version that created it. Because the chain is immutable, verifying a payment’s history becomes fast and reliable.

The subscription fee is the cost of producing this verifiable record.
Attack surface

Unilateral fraud becomes structurally impossible.

CAST eliminates the class of fraud that depends on one party acting without the other's knowledge. Collusion isn't eliminated — but it becomes documented and detectable rather than invisible.

  • ✓Email is not the confirmation channel. Owning the inbox does not produce a bilateral event — the passkey device does.
  • ✓Bank change is a hard-coded trigger. Not policy-configurable. Confirmation required via passkey.
  • ✓No verbal instruction has a pathway in. Payment requires a bilateral event. No exceptions.
  • ✓Rush payments increase scrutiny. Override needs dual approval and a constrained reason code.
Attack vector
Before
After
Fake invoice — external
Undefended
Eliminated
BEC — bank-change fraud
Undefended
Eliminated
Compromised vendor email
Undefended
Eliminated
Verbal social engineering
Fully effective
Eliminated
Duplicate invoice
Partially caught
Structural
Rush-payment bypass
Common failure
No path
Vertical-agnostic by design

AP proves the architecture. Every other vertical is configuration.

The four layers don't change between use cases. Only event types, policy rules, and Work Order structures do. CAST sits alongside your ERP — not in place of it — and produces posting-ready exports with the lineage hash in the memo field.

  • →BEC fraud prevention — Highest risk reduction for CFOs and controllers
  • →Port dispute rescue — Freight forwarders and importers
  • →Audit remediation — Public companies and PE-backed firms
  • →Lender-mandated controls — ABL lenders and factors
  • →Intercompany transfers — Shared authorization eliminates month-end reconciliation
verify.ts — independent replay 
// Any third party, no counterparty contact
const ok = await replay(eventId);

// Standard libs only — no proprietary verifier
- SHA256(canonicalize(payload, v1))
- ECDSA-P256 signature check
- X.509 chain validation

return {
  valid: ok,
  proves: "both parties confirmed",
  at: "signed timestamp",
  unmodified_since: true
};

The proof is produced once, at transaction time.

It travels with the payment through every downstream system. That's what makes a transaction insurable, financeable, and survivable in audit.

Request a demo → Vision & architecture — Field Guide →
Mutual Authorization

Confirm vendor payments before they move.

CAST adds a mutual authorization step to AP payments. Vendors confirm exact details via a secure link before funds are released.

Request a demo → See how it works
POST /v1/work-orders/wo_8fa2/confirm 
# Vendor confirms before payment release
{
  "event":        "bilateral.confirmed",
  "work_order":   "wo_8fa2c1",
  "payment": {
    "invoice":    "INV-1048",
    "amount":     "47000.00",
    "currency":   "USD",
    "pay_date":   "2026-05-22",
    "bank_last4": "4821"
  },
  "signature": {
    "method":    "passkey_or_verified_link",
    "bound_to":  "work_order_hash",
    "signer":    "vendor_contact"
  },
  "policy_version": "POL-v1",
  "lineage_hash":  "7c0d...b48a"
}

-> Covered payment blocked until vendor confirms.
-> Proof record retained for audit and review.
bilateral_stateconfirmed
control_stateapproved
releaseunblocked
$2.9B
Annual U.S. BEC losses
1 of 2
Parties confirming terms today
0
Covered payments released before confirmation
1
Bilateral record for every covered release
The root cause

AP today is one-sided.

The payer approves an invoice internally. The vendor learns of the transaction only when money arrives, when it does not arrive, or when something is already wrong.

CAST adds one narrow control: before a covered payment is released, the counterparty confirms the payment details through a secure Trade Message.

Mutual Authorization Loop

One party proposes. The vendor confirms. Policy governs release.

Confirm & Pay is a pre-release AP control. It does not replace the ERP, create seller-side ledgers, or require vendors to adopt a new system.

01 · Propose□

High-risk payment identified

Your rules flag a payment that needs mutual authorization (first vendor, bank change, high value, rush, etc.).

02 · Send↗

Secure link sent to vendor

The vendor receives a simple browser link showing the amount, invoice, date, and bank details. No login or app required.

03 · Authorize✓

Vendor provides mutual authorization

The vendor reviews and authorizes the payment details (or requests a change / disputes). This creates the binding authorization record.

04 · Release→

Payment proceeds with proof

Only after mutual authorization does the payment release. A clear, verifiable record is created automatically.

What the vendor sees

A secure payment card. Three actions. No integration.

The vendor is a counterparty signer, not a full CAST tenant. They do not need an app, ERP connection, or account setup to confirm a payment.

✓Confirm
!Request change
×Dispute
Precise claim: CAST proves the vendor confirmed these payment terms for this specific payment record at this timestamp. It does not claim the invoice is inherently real, and it does not eliminate collusion.
CAST Trade Message

Confirm payment

✓
PayerAcme Apparel Co.
VendorRiverdale Textiles
InvoiceINV-1048
Amount$47,000.00
Pay dateMay 22, 2026
Destination•••• 4821

Confirm only if these details match the payment you expect. Any change keeps the payment held.

Covered AP controls

Start where payment risk is concentrated.

Confirm & Pay focuses on the payments where one-sided approval creates the most risk.

U

First payment to a vendor

A new vendor relationship should not receive funds without counterparty confirmation of the destination details.

✓

Bank-account change

Any destination-account change triggers confirmation. The vendor sees the bank last four before release.

!

Rush payment

Urgency increases scrutiny instead of bypassing controls. A rush payment still waits for confirmation.

$

High-value threshold

Payments above your configured threshold require a bilateral event before proceeding.

#

Duplicate-risk invoice

Potential duplicate invoices are sent for confirmation or held for review before money moves.

?

Dispute or non-response

If the vendor disputes or misses the deadline, the payment remains held and the exception is recorded.

Interactive walk-through

One AP payment, three lenses.

Follow one invoice from payment intent to vendor confirmation to retained proof.

Buyer view · AP control queue

High-risk payments wait for the vendor.

First payment, bank change, rush payment, duplicate-risk invoice, or threshold breach. Your team can see what is waiting, confirmed, disputed, or expired.

held
INV-1048Riverdale Textiles$47,000Awaiting vendor
INV-1049Pacific Packaging$8,250Confirmed
INV-1050Kestrel Hardware$14,800Change requested
Confirm & Pay sits before payment release and alongside existing AP systems.
Proof record

Every authorized payment leaves behind a clear record.

Confirm & Pay records who confirmed, what they confirmed, when they confirmed it, which policy governed the release, and which payment record the confirmation was bound to.

Vendor confirmation before payment release
Payment details snapshotted at confirmation time
Policy version retained with the event
Record available for audit, review, and dispute resolution
Confirmation record

A payment-specific proof package

verified
Counterparty
Riverdale
vendor signer
Payment
$47,000
INV-1048
Destination
•••• 4821
confirmed before release
event_type: bilateral.confirmed
work_order_id: wo_8fa2c1
policy_version: POL-v1
lineage_hash: 7c0d...b48a
release_status: approved_after_confirmation
Built for AP teams

A control layer that sits before payment release.

CAST works alongside existing AP and ERP systems. It creates the counterparty confirmation record those systems do not produce on their own.

✓

Pre-release control

Covered payments remain held until the vendor confirms the payment terms or an exception is reviewed.

↗

Low-friction vendor experience

Vendors receive one secure link and confirm in the browser. No vendor-side ERP connection is required.

#

Audit-ready evidence

Each confirmation creates a retained record of the terms, signer, timestamp, policy version, and payment reference.

Confirm & Pay

Add counterparty confirmation to high-risk AP payments.

CAST gives finance teams a bilateral proof layer before payment release, without replacing the ERP or asking vendors to adopt a new system.

Request a demo
Confirm first payments and bank-account changes
Hold payment when details are disputed or unconfirmed
Retain a payment-specific proof record
Operate alongside existing AP and ERP workflows

Request a demo

See Confirm & Pay walk one payment from intent to vendor-confirmed proof. We’ll be in touch.

Or reach out directly · contact@digitalfinancehq.com

Thank you.

We’ve received your request and will reach out shortly.