VoxFence / Enterprise payment authorization
A convincing call is not payment authorization.
In a synthetic $25.6 million wire instruction, a supplied 0.90 authentic score looks reassuring. We show how VoxFence's deterministic policy gate blocks it using payment context and supplied endpoint flags before a simulated treasury rail can execute.
$25.6 million
instruction blocked despite a high supplied score
Synthetic worked case
2/2
synthetic fraud cases stopped
Six fixed labeled scenarios
0/4
legitimate cases ultimately stopped
Includes one simulated verification step
This is an authorization architecture demonstration with synthetic signals, simulated integrations and cached advisory replies, not an operational deepfake detector.
Separate persuasion from permission
Treasury and security teams need to ask two different questions: does a call look authentic, and is this payment independently authorized? Treating the first answer as permission to move money leaves the beneficiary and approval process outside the decision.
The synthetic anchor case combines a video-only instruction, new beneficiaries, an unattested endpoint and an injection flag. Its high supplied score changes none of those facts. The useful review question is which evidence can actually stop execution at the payment boundary.
How the policy gate decides
VoxFence normalizes payment context and supplied call/device flags. Eight deterministic rules report findings; code makes the binding decision. The supplied detector score and cached advisory paragraph cannot change a gate branch.
| Configured condition | Decision | Simulated final outcome |
|---|---|---|
| Amount below $50,000, regardless of other risk flags | AUTO_APPROVE | EXECUTED |
| Amount at least $50,000; known beneficiary, corroborated approval, attested endpoint and no injection flag | AUTO_APPROVE | EXECUTED |
| Other instructions at least $50,000 with injection flagged or an unattested endpoint | BLOCK | BLOCKED, with simulated security escalation; callback cannot release it |
| Remaining instructions at least $50,000, including new beneficiaries or uncorroborated video-only approval | STEP_UP | EXECUTED after a reachable, authorized simulated callback; otherwise HELD |
Corroboration means a ticketed or dual-approved channel, or a supplied second-approver flag. Independent verification uses a simulated pre-registered channel outside the call. A production channel would need dependable contact details and authority that the caller cannot choose.
The exported decision pack retains signals, fired-rule identifiers, decisions and callback outcomes in a SHA-256 hash chain with an HMAC-SHA256 signature. Local verification detects the demonstrated record edit under the demo key assumptions. The default signing key supplies no protected production custody, and the records are not immutable.
Follow the instruction from call to payment decision
These are captures of the current VoxFence interface with explicit scope headers. All cases, names, scores, flags and callback responses are synthetic. Legacy incident, insurance and standards assertions visible in the source interface are unverified, not evidence for the claims on this page.
Worked example: $25.6 million, 15 transfers, five new beneficiaries
The prepared instruction arrives only through an illustrative video call. It names five new beneficiaries in Hong Kong, has no corroborated approval, and supplies an unattested-device flag and an injection flag. Its supplied P(authentic) is 0.90.
That score is an input, not a measurement made from the pictured call. The payment question is whether the configured gate permits execution. Here the answer is BLOCK, followed by BLOCKED in the simulated treasury path.
1. Keep the payment boundary separate from the call
The selected instruction and its final outcome appear together. A reassuring score does not authorize this high-value instruction. The other visible cards are separate synthetic fixtures, not additional transfers within this case.
2. Inspect the supplied inputs and the binding branch
The findings explain the context, but the gate's branch is narrower: this amount exceeds the $50,000 threshold, does not meet the corroborated auto-approval conditions, and has an injection flag and an unattested endpoint. Either of those endpoint conditions is sufficient for BLOCK in this branch. The new beneficiaries and video-only channel explain why independent approval is missing; the detector score is not a branch condition.
| Supplied context | Worked-case value | Role in the gate |
|---|---|---|
| Amount | $25,600,000 | Uses the high-value branch |
| Beneficiary and approval | Five new payees; video-only, no corroboration | Does not qualify for high-value auto-approval |
| Endpoint flags | Unattested; injection flagged | Triggers BLOCK for this high-value branch |
| Detector score | P(authentic) = 0.90 | Displayed input, not payment authority |
3. Record the independent callback without weakening BLOCK
The simulated pre-registered callback reports that the request was not authorized. The final outcome stays BLOCKED and the security escalation is simulated. A positive callback would not release a BLOCK instruction either: callback authorization can release STEP_UP, not erase the BLOCK branch. The cached analyst paragraph explains the outcome but cannot alter it.
4. Retain the decision record, not just a screenshot
The decision-pack export records supplied signals, fired-rule identifiers, gate decisions, final outcomes, callback data and advisory fields. It does not serialize every detailed finding object displayed in the interface. The illustrated export contains six synthetic records, including the blocked anchor and the legitimate release shown below. Its legacy filename uses Sentinel; the current demonstration is VoxFence.
5. Check local integrity, then test a record edit
The unaltered pack passes the local chain and HMAC check. The separate tamper exercise changes the $250,000 fixture's amount to $1; verification then reports a record-hash mismatch. This checks the demonstrated edit under the demo's key assumptions. It does not prove who originated the inputs, prevent rewriting and re-signing with the default key, or create immutable storage.
Verification can also release business
Contrast the blocked case with a synthetic $2 million payment to one new US beneficiary. Its supplied endpoint is attested and has no injection flag, but video-only approval does not satisfy high-value auto-approval. The gate takes STEP_UP; a reachable, authorized simulated callback then permits EXECUTED. If that callback were unreachable or denied authorization, the STEP_UP outcome would be HELD. No real funds move in either path.
Select any capture to inspect it at full size.
What the comparison establishes
The same six fixed synthetic labeled scenarios contain two fraud cases and four legitimate cases. Detector-only blocks when the supplied P(authentic) is below 0.85; pass-through executes every instruction. These are configured architecture comparisons, not commercial product rankings.
| Configured approach | Synthetic fraud stopped | Legitimate cases stopped | Synthetic fraud amount allowed |
|---|---|---|---|
| Pass-through | 0/2 | 0/4 | $26,099,000 |
| Detector-only | 1/2 | 1/4 | $25,600,000 |
| VoxFence policy gate | 2/2 | 0/4 | $0 |
All four legitimate fixtures ultimately execute under the gate. One requires a simulated callback, so zero legitimate cases stopped does not mean zero friction. The finite test provides no production prevention rate, latency result or customer savings claim.
What this demo does NOT do
It does not analyze real frames, measure liveness or run live banking, conferencing, attestation, callback or security-notification connectors. Those integrations are simulated. The recorded dashboard serves cached Codex advisory replies, and the benchmark runs without a model call.
Deployment would require reliable signal acquisition, enforced treasury integration, secure independent verification, protected keys and operational validation. The current under-$50,000 branch auto-approves regardless of other risk flags. That coverage limitation must be resolved or explicitly accepted before adopting this policy.
Questions treasury and security teams ask
Can a convincing video call authorize a wire transfer?
A convincing call does not supply independent payment authorization. VoxFence demonstrates a separate policy gate that checks payment context and supplied endpoint flags before allowing simulated execution. In its synthetic $25.6 million case, a supplied 0.90 authentic score does not override the BLOCK decision.
Does VoxFence detect deepfake video itself?
This demo does not analyze real video frames or operate a deepfake detector. Its detector score, device-attestation flag and injection flag are synthetic inputs; the call imagery is illustrative. Detector confidence is not a decision condition in the current gate, and the recorded advisory text comes from cached Codex replies.
What happens when a large payment is legitimate?
A synthetic $250,000 instruction auto-approves because its known beneficiary, attested endpoint and dual approval meet the configured checks. A synthetic $2 million instruction to a new beneficiary instead requires independent verification and executes after a simulated authorized callback. Step-up adds friction even when a legitimate instruction ultimately executes.
Where does the independent confirmation come from?
The demo uses a simulated pre-registered callback channel outside the video call. A STEP_UP instruction executes only when that callback is reachable and authorizes it; otherwise it remains HELD. A BLOCK decision remains BLOCKED even if the callback reports authorization. Production use would require a secure channel whose contact details and authority cannot be supplied by the caller.
What does the six-scenario result actually prove?
On six fixed synthetic labeled scenarios, the VoxFence gate stops 2/2 fraud cases and ultimately stops 0/4 legitimate cases. The configured detector-only comparison stops 1/2 fraud cases and stops 1/4 legitimate cases, using a supplied P(authentic) cutoff below 0.85. These results demonstrate the tested decision paths, not commercial detector accuracy or operational fraud prevention.
What would need to change before production use?
Production adoption would require dependable signal acquisition, enforced treasury integration, secure independent verification, protected signing keys and operational validation. The current gate auto-approves amounts below $50,000 regardless of other risk flags, so its low-value coverage needs explicit redesign or acceptance. The local hash chain uses a default demo key and does not establish independent custody or immutable records.
Technical Research
Explore related research for broader context on this demonstration.
Inspect the boundary that releases funds
Discuss payment authorization architecture with our team.
We can help frame the signals, independent approvals and enforcement a production design would need. This walkthrough is evidence of configured behavior, not a deployment guarantee.
Authorization assessment
- ✓ Payment approval boundaries
- ✓ Signal trust and acquisition
- ✓ Independent channel design
- ✓ Low-value coverage decisions
Implementation planning
- ✓ Treasury enforcement design
- ✓ Verification and release paths
- ✓ Signing-key protection
- ✓ Operational validation plan
