Treasury workflow holds the wire
The treasury console pauses release, surfaces the risk flags, and displays the wire payload — beneficiary, bank, country, amount, originating account.
← All use cases
Integration pattern · Illustrative scenarios and policy values. Confirm supported signals, processing location, and application enforcement for your deployment.
The pattern: hold, attest, release
A trusted-looking message can pressure someone into approving a fraudulent payment. Showing the exact transaction during verification gives the approver a separate opportunity to inspect and decline it.
When the treasury workflow detects a sensitive wire, it pauses and opens a BioTone session whose payload is the wire itself. The approver sees the wire details on their phone, completes a multi-signal capture, and the signed assertion is what permits release. If the approver is on a hostile call, they see — and can decline — what they are actually being asked to authorize.
When the workflow pauses for an attestation
Triggers are configured per organization. Common defaults operators start with:
- First-time beneficiary on the corporate counterparty list.
- Amount above the operator-defined auto-approval threshold.
- Outside business hours, or originating from an unusual location.
- Initiated through video or voice — channels where deepfake risk is highest.
Lower-risk wires can stay on whatever existing approvals you already use; the BioTone step appears only when the policy says it is needed.
End-to-end flow
From the treasury console hold to wire release — the same pattern we ship in the Apex Treasury demo.
BioTone challenge bound to the wire
The console opens a BioTone session whose action_context carries the exact amount, currency, beneficiary, and a 90-second expiry. The approver sees those same details on their phone before any biometric capture begins.
Multi-signal capture on the approver's handset
The enrolled phone captures the signals required by policy. Processing and data custody depend on the deployment mode; the treasury backend validates the verification result before releasing the payment.
Wire releases (or stays held)
In the proposed integration, the treasury backend validates a timely approval before release and records the result. Failed or expired requests remain held for review.
What the audit log captures
Every attempt — success, failure, or expiry — produces a record your audit, fraud, and IR teams can pull alongside the treasury system's own log:
- Approver subject id (mapped to your IdP user record).
- Available matcher results: periocular, palm, ear, and voice; presentation and pulse checks support liveness.
- Fused assurance level and the policy threshold it cleared.
- Action context: amount, currency, counterparty, originating account, expiry.
- Issuer JWKS key id and the signed broker assertion itself.
The signed assertion is the artifact a forensic review can independently verify — no need to trust the treasury vendor's own log alone.
Apex Treasury wire-transfer demo
Bring a representative wire payload (amounts, counterparty metadata, your current approval rules) and we will reproduce it end-to-end with a phone in the room.