Compliance as a feature, not a checkpoint
The rules are written down, they rarely change, and they apply to every competitor equally. Taking a KYB platform to SOC 2 Type 1 readiness turned them into a better spec than most we are handed.
In regulated industries, compliance is the standard reason nothing gets modernized. Every proposal stalls in legal review, so the software stays old and the workarounds pile up around it.
Building a KYB platform for a fintech startup — verifying business buyers before a trade-credit decision — taught us the opposite. UK GDPR, the Money Laundering Regulations and PSD2 ask for a lot, but what they ask is written down, changes slowly, and applies to every competitor the same way. A requirement you can read is a specification. The rest of this post is what happened when we treated it as one.
The decision the platform exists to make
Every screen in the product serves one question: can this buyer get trade credit? Answering it means pulling from company registries, credit bureaus, sanctions lists, VAT validation and Open Banking — five sources, no two of which agree on a format, a response time or an uptime.
- Every source sits behind an adapter that returns one shape; the scoring code never sees a provider-specific payload
- Each check is an idempotent step in a durable workflow — a timeout at the credit bureau retries that step, it does not restart the run from the registry
- The score is weighted, and the weights, the inputs and their timestamps are stored with the result, so a decision can be explained months later — MLR expects exactly that audit trail
- A provider outage lowers the confidence of the score; it does not take the platform down
Decisions the rules made better
Each of these started as an obligation and ended up better than what we would have chosen on our own.
- Envelope encryption with a data key per tenant under a managed master key: a GDPR erasure becomes a key destroyed, not a hunt through the database and every backup of it
- Passkeys with signed stateless sessions: no passwords to leak, no phishing surface, and no session table to keep in sync across instances
- STRIDE threat modeling before the first line of code: the sign-in path gives nothing away, not even in its response time
- A strict Content Security Policy from day one, which costs a fraction of retrofitting one onto a product full of inline scripts
One tenant, one blast radius
The platform is multi-tenant, and in fintech that is a compliance boundary before it is an architecture choice: data leaking between two tenants is a failure of the whole company, not of one account.
- Tenant scoping is enforced at the data layer, not in every handler — a query without a tenant is a bug the code cannot express
- A test suite that deliberately tries to read across tenants, and must fail, runs on every build
- A key per tenant means a compromised key is one tenant, never the customer base
Put the guarantees in the pipeline
What made SOC 2 Type 1 readiness achievable was moving the guarantees out of documents and into CI: integration tests against real database branches, architectural rules checked on every build, and an environment that stands up from code — no hand-built infrastructure, no stored secrets. An auditor who can read the pipeline needs far fewer meetings.
A control a build can verify survives staff turnover, deadline pressure and Friday afternoons. A control that lives in a document survives none of them.
If your compliance work ends in a PDF, you have written the spec. Now build it.