I’ve been thinking about what happens when a regulator walks in and asks a crypto exchange to prove that a specific human authorized a specific withdrawal on a specific date.
The exchange pulls up a log. A row in a database. Timestamp, user ID, amount, IP address. Maybe a session token reference. Maybe a 2FA confirmation code.
The auditor asks: how do you know a human was physically present when this happened?
The log can’t answer that. The session token can’t answer that. The 2FA code can’t answer that. What the exchange actually has is a record that says someone who had access to the right credentials performed an action. That’s it. That’s the entire audit trail.
The auditor doesn’t want a log entry. They want a receipt — independently verifiable proof that a specific human was physically present at the moment the money moved.
What auditors actually need
Compliance in financial services comes down to three questions. Every audit, every regulatory inquiry, every dispute resolution starts here:
1. Who authorized this action? Not which account. Not which session. Which human being.
2. When exactly did they authorize it? Not when the session started. Not when the transaction settled. The exact moment of authorization.
3. Can you prove it independently? Not “our database says so.” Can a third party verify this without trusting your infrastructure?
Most platforms can answer #1 with an account ID, #2 with a database timestamp, and #3 not at all. That’s the compliance gap.
The database log problem
Database logs are mutable. Even with append-only configurations, the entity that controls the database can alter the records. This isn’t a hypothetical — it’s the foundational objection any opposing counsel will raise in a dispute.
“Your honor, the defendant’s own database says the transaction was authorized. The defendant controls the database.”
The log is evidence that something happened in your system. It is not independent proof that a human authorized it. There’s a legal distinction between a record you created and a receipt that can be verified without trusting you.
This is why transaction signing matters in traditional finance. This is why notarization exists. This is why the entire concept of non-repudiation exists in cryptography. The proof has to be verifiable by parties who don’t control the system that created it.
What a JWT gives you that a log doesn’t
When Lorica verifies a human before an action, the JWT that comes back is structurally different from a database log. Here’s what’s inside:
{
"user_id": "trader_jane",
"match": true,
"confidence": 0.97,
"confidence_level": "high",
"liveness_score": 0.91,
"liveness_method": "motion",
"action_verified": "withdrawal_500k_to_external",
"verification_id": "a7c2...4f1e",
"verified_at": "2026-03-28T09:14:33.221Z",
"session_duration_ms": 500,
"capture_hash": "e8b4...c912",
"iat": 1774893273,
"exp": 1774893573
}Every field in that token answers a specific compliance question:
user_id + confidence + liveness_score — this specific human was biometrically confirmed present. Not a session token. Not a 2FA code. A live face match against their enrolled biometric at 97% confidence with motion liveness.
action_verified — the verification was scoped to a specific action. The human didn’t just “log in.” They authorized this withdrawal, this amount, this destination.
verified_at + session_duration_ms — the exact timestamp with millisecond precision. The verification took 500 milliseconds. This is the moment of authorization, not the moment of settlement.
capture_hash — the SHA-256 hash of the biometric capture. The image itself is never stored. The hash proves the capture existed without exposing the biometric data. Replay attempts against this hash are detected and rejected.
Independent verifiability
The token is signed with HS256. The signing secret is a shared signing secret delivered to integrators at onboarding. Any party holding that secret can verify the token’s signature without calling Lorica’s API, without accessing the exchange’s database, and without trusting either party’s infrastructure at runtime.
That’s non-repudiation. The exchange can’t claim the token was forged. The user can’t claim they didn’t authorize the action. The token exists, the signature is valid, and the biometric confirmation is embedded in the payload.
A database log says “our system recorded this.” A signed JWT says “this happened, and you can verify that independently without trusting us.”
The regulatory trajectory
MiCA in Europe. The OCC’s evolving guidance on digital asset custody. Hong Kong’s VASP licensing regime. Every regulatory framework being built right now is moving in the same direction: platforms must demonstrate that specific humans authorized specific actions, and the evidence must be independently auditable.
The exchanges that can produce a signed, timestamped, biometrically-verified receipt for every high-risk action are the ones that will pass audits cleanly. The ones that can only produce database logs will spend months in remediation.
OKX paid $504 million because their compliance infrastructure couldn’t answer the basic question. Not because they didn’t have logs. Because their logs couldn’t prove what regulators needed them to prove.
The cost of not having the receipt
When a dispute arises and you can’t prove a human authorized the action, three things happen:
1. You eat the loss. Without independent proof of authorization, the dispute resolution defaults to the customer. The platform absorbs the liability.
2. The regulator flags it. One unresolved dispute is a footnote. A pattern of unresolved disputes is an enforcement action.
3. Your insurance premium goes up. Underwriters price risk based on your ability to prove authorization. Weaker proof means higher premiums or reduced coverage limits.
A Lorica verification is sub-cent latency. It produces a receipt that survives legal scrutiny, satisfies regulatory inquiry, and provides the independent verifiability that auditors actually need.
Your database log is a record. Our JWT is a receipt. When the auditor walks in, they want the receipt.
Give them the receipt.