A treasury team receiving a wire instruction over a video call has two decisions to make. Does the caller appear authentic? And is this particular payment authorized? A system that answers the first question still needs a defensible answer to the second before funds move.
We designed the VoxFence demonstration around that separation. It places a deterministic policy gate between a wire instruction and a simulated treasury rail. Supplied payment and endpoint checks decide whether the instruction proceeds, requires independent verification, or is blocked. The useful question for a treasury leader and their security partner is which evidence can actually release the payment.
A high score with no authority to transfer
Consider the demonstration's synthetic $25.6 million wire instruction. It requests transfers to new beneficiaries through a video-only approval channel. Its supplied authenticity score is 0.90, but the endpoint is marked unattested and an injection flag is supplied. VoxFence returns BLOCK, and the simulated rail leaves the instruction BLOCKED.
That score is a chosen fixture input, not a measured or calibrated probability. The call imagery, signals and callback responses are synthetic or illustrative. VoxFence does not analyze the footage to establish the caller's identity or detect injection. The demonstration tests what a payment policy does with supplied evidence.
The synthetic instruction remains blocked despite its high supplied score. Call imagery and overlays are illustrative; integrations are simulated.
The distinction becomes clear against the configured detector-only comparator. That comparator blocks when the supplied authenticity score is below 0.85. On the same synthetic instruction, 0.90 clears its cutoff. The policy gate still blocks because the high-value instruction carries an injection flag and an unattested endpoint. This is a comparison of configured decision rules, not a finding about a commercial detector's accuracy.
Changing the detector score would not change this gate decision. Detector confidence is not a condition in any of its authorization branches. A favorable score cannot clear the supplied endpoint failures, establish an approved beneficiary, or supply a second approval.
For someone assessing a payment control, that is an inspectable property. Ask whether a favorable detector result can override a missing authorization condition. If it can, the detector has acquired authority to release money, even if the interface describes its output as merely advisory.
The boundary needs to be explicit
The high-value boundary in this implementation is $50,000 inclusive. At or above that amount, a known beneficiary, corroborated approval, an attested endpoint and no injection flag permit automatic approval. Corroboration comes from a ticketed or dual-approved channel, or a supplied second-approver flag. A large amount alone does not require a callback.
Other high-value instructions with an injection flag or an unattested endpoint are blocked. Where those strong flags are absent, a new beneficiary or an uncorroborated video-only request routes to STEP_UP, requiring verification outside the call. These are different responses to different evidence gaps. An instruction awaiting confirmation has a defined path to release; a blocked instruction does not silently become executable when a callback reports authorization.
The lower branch deserves equal attention: below $50,000, this implementation auto-approves regardless of the other risk flags. It does not demonstrate complete protection for smaller payments. We would treat that branch as a deployment decision to revisit, rather than let a successful high-value example conceal it. The threshold is a configured demo boundary, not an externally mandated rule.
Verification must explain how business resumes
A control that only demonstrates refusal leaves a practical question unanswered: what happens to an unusual payment that is legitimate?
The synthetic $2 million instruction provides that complication. It names a new beneficiary and arrives through video-only approval, but its supplied endpoint is attested and it has no injection flag. VoxFence routes it to STEP_UP. A simulated callback through a pre-registered channel authorizes the instruction, after which the simulated rail reports EXECUTED. Without reachable, authorizing confirmation, the step-up path remains HELD.
The callback is a simulated adapter, not an actual phone call or banking integration. Its value in the example is the release condition it makes visible: the video instruction cannot supply its own missing confirmation. The policy waits for evidence from a channel registered outside that exchange.
The synthetic $2 million instruction requires a simulated pre-registered callback before release. The green callback panel records authorization; the standards labels are illustrative and unverified.
This adds friction to the legitimate case. We would not describe eventual execution as frictionless. The relevant distinction is whether the delay has a defined purpose and an explicit exit condition. A step-up that cannot explain what will satisfy it can become an indefinite operational hold. A release path that simply asks the same caller to confirm again has not established independence.
What the demonstration leaves for deployment
The paired cases expose useful policy behavior, but the reliability of a deployed control would depend on how it obtains its signals and enforces its decisions. In this demonstration, the detector, endpoint attestation, treasury rail and callback are simulated. The dashboard uses cached Codex-generated advisory text; that text explains findings and cannot change the binding decision. None of this establishes production detection performance or a functioning bank integration.
For a production design, we would require evidence that the payment cannot bypass the gate, that endpoint and approval signals come from dependable sources, and that the independent verification channel cannot be supplied by the caller. A record that a callback was configured is not evidence that a real independent approver confirmed a transaction. Those are implementation and operational validation tasks.
The VoxFence breakdown explains the mechanism and its limits. When assessing a design like this, follow an instruction all the way to the release condition. Identify the evidence that permits execution, the evidence that vetoes it, and what happens when confirmation never arrives. That examination gives treasury and security a concrete basis for accepting the control, or identifying the payment path it still leaves open.