Transaction attestation against deepfake and BEC fraud
One artifact: a signed, ledgered attestation.
PAROLE proves that an enrolled person, under user verification, at a specific moment, approved or repudiated one specific structured transaction. Payment systems require a valid attestation id before executing. Enforcement is the product; nobody has to feel brave enough to challenge a CFO, because the form has a mandatory box.
Sign in
Sign in with your corporate identity provider. A phishing-resistant sign-in method is required; anything else is rejected with an explanation, not a silent downgrade.
Continue with your organizationWhat this stops
In scope
- Synthetic voice or video impersonating an enrolled employee
- Business email compromise, including vendor bank-change fraud
- Replay of anything previously spoken or shown
- Stolen web sessions and coerced insiders
Out of scope, documented not solved
- Malware controlling the enrolled device at assertion time
- An approver correctly told the fraudulent intent and approving it anyway
- IdP compromise
- Availability attacks: if PAROLE is down, the answer is no
The ceremony
1. An ERP, payment run, or ticketing system requests an attestation for one structured transaction over the enforcement API.
2. The request lands on the enrolled approver's desk as a field card: one labeled field per line, amount and account number visually dominant.
3. Attest or deny, under a fresh passkey assertion bound to this exact transaction. Ten seconds, no "are you sure".
4. Higher tiers add a spoken phrase ceremony and a second attester before a token issues.
5. The outcome is written once, permanently, to a tamper-evident ledger, and the payment system checks a signed token before it acts.