What retrofits and what doesn’t

There’s a pattern in financial infrastructure that repeats so reliably it should be a law: platform launches, platform scales, platform gets breached, platform retrofits security. The breach is the catalyst. The budget appears after the damage.

This works for some security measures. You can add rate limiting after launch. You can add DDoS protection after the first attack. You can implement WAF rules after the first injection attempt. These are operational security layers — they bolt on.

But there’s a category of security that doesn’t bolt on.

Trust infrastructure has to be architectural.

And the distinction between what you can retrofit and what you can’t is the difference between platforms that survive breaches and platforms that don’t.

You can bolt rate limiting on after the first DDoS. You cannot bolt identity proof on after the first wire that wasn’t actually authorized — that proof either existed at the moment, or it never will.

Operational layers (can be added after launch):

  1. Rate limiting — Yes. Middleware. No schema changes. Ship in a day.
  2. WAF / DDoS — Yes. Proxy layer. Cloudflare in front, done.
  3. Input validation — Yes. Validation middleware. Incremental.
  4. Encryption at rest — Yes. Migration is painful but possible.

Architectural layers (cannot be retrofitted):

  1. Biometric enrollment — No. Requires every user to re-onboard. Months of migration. Churn risk.
  2. Action-level verification — No. Requires rewriting every transaction path. Breaking API changes.
  3. Cryptographic audit trail — No. Past transactions have no proof. Gap in audit history forever.
  4. Non-repudiation — No. Can’t retroactively prove a human authorized past actions.

Layers 1 through 4 are operational. They protect the perimeter. They can be added incrementally without changing the core transaction flow. Every mature platform has them.

Layers 5 through 8 are architectural. They require changes to the user onboarding flow, the transaction execution path, the data model, and the audit infrastructure. Adding them after the fact means migrating every existing user, rewriting every transaction endpoint, and accepting a permanent gap in your audit trail for everything that happened before the migration.

You can’t retroactively prove a human authorized a transaction that already happened. The proof either exists at the moment of the action or it never exists at all.

The retrofit tax

When a platform decides to add biometric verification after a breach, here’s what actually happens:

Month 1–2: Enrollment migration. Every existing user needs to complete a biometric enrollment. This means building an enrollment flow, emailing every user, handling the inevitable support tickets (“why do you need my face now?”), and dealing with the 15–30% of users who won’t complete it. Those users either get exempted — creating a security gap — or get locked out — creating churn.

Month 2–4: Transaction path rewrite. Every high-risk action needs a verification gate. This isn’t adding middleware — it’s changing the transaction execution flow. The withdrawal endpoint now needs to call a verification API, wait for the result, handle timeouts, handle failures, and conditionally proceed. Every endpoint. Every action type. Every edge case.

Month 4–6: Audit trail reconciliation. The compliance team now has two eras of data: “before biometric verification” and “after.” Every audit, every regulatory inquiry, every dispute has to specify which era the transaction falls in. The gap is permanent. Three years from now, an auditor will ask about a transaction from Month 3 and the answer will still be “that was before we had verification.”

Total cost: six months of engineering, product disruption, user churn, and a permanent audit gap. All to add something that could have been a POST /verify call on day one.

The day-one architecture

Here’s what it looks like when verification is built in from the start:

// User signs up → enroll biometric immediately
POST /enroll
{
  "user_id": "new_user_jane",
  "image": "base64_face_capture..."
}
// Response: enrolled in 1.2s. Done once. Never again.

// User initiates any high-risk action → verify
POST /verify
{
  "user_id": "new_user_jane",
  "image": "base64_live_capture...",
  "action_context": "withdrawal_100k_to_external",
  "liveness_mode": "passive"
}
// Response: JWT with human proof. Attach to transaction.
// Every action, from day one, has cryptographic proof.

Two API calls. One at onboarding, one before each high-risk action. The enrollment happens naturally during user signup — it’s a face capture in the registration flow, not a separate migration step. The verification happens naturally before the action — it’s a step-up check in the transaction path, not a bolted-on gate.

Every transaction from the first day has a signed JWT. Every audit has a complete trail. Every user enrolled during their normal onboarding. No migration. No gap. No retrofit tax.

Why the timing matters now

If you’re pre-launch or early-stage, this is the cheapest decision you’ll ever make. Adding Lorica to your transaction path before you have users is a few hours of integration work. Adding it after you have 50,000 users is a six-month project with a 20% churn risk.

The regulatory trajectory makes this urgent. MiCA enforcement is tightening. The OCC is increasing scrutiny on digital asset custody. Hong Kong’s VASP regime is live. Every framework being built right now assumes platforms can produce human-level authorization proof. The platforms that baked it in from day one will pass audits cleanly. The platforms that retrofit will spend months explaining the gap.

And the competitive dynamic is shifting. When one exchange in a market segment can show auditors a cryptographic proof trail for every high-risk transaction and its competitors can only show database logs, the compliance advantage compounds. Institutional clients notice. Insurance underwriters notice. Regulators notice.

The cost of starting now vs. starting later

Starting now: Single-sitting integration. Complete audit trail from transaction #1. Zero migration risk.

Starting after the breach: 6 months of engineering. 15–30% enrollment churn. Permanent audit gap. Breaking API changes. Regulatory scrutiny during the migration.

The breach hasn’t happened yet. For most platforms, it will. The question is whether the trust infrastructure is in place when it does — or whether the breach is the event that forces a painful, expensive, incomplete retrofit.

Every security layer that can be bolted on should be. Rate limiting, WAF, input validation — add them whenever you want. But biometric verification, action-level proof, and cryptographic audit trails are architectural. They’re either in the foundation or they’re not.

You don’t get to add trust after the breach. Build it before.