Problem
A MiFID II investment firm must know its client, check that a product is appropriate for them, know where their money comes from, monitor their transactions, and keep records that a supervisor can request at short notice. When those duties live in manual processes, spreadsheets, or the user interface, two things happen: the evidence is slow to produce, and the controls can be bypassed.
At Assetera, trading settles on public blockchains. That adds a duty most brokers do not have: a smart contract must not execute a trade that the compliance rules would refuse.
Constraints
The regulator's question decides the design. For each control the first question was "what must we be able to prove, and to whom", then "where in the system is that proof produced".
No control only in the browser. Anything a client can skip in the frontend is not a control.
Compliance officers must be able to act. Reviews, decisions, and overrides need a proper admin surface, and every action there is audited.
Vendors change. KYC and screening providers are replaceable. Their data must end up in our own model, not stay locked in theirs.
Architecture
Onboarding. KYC and KYB with Sumsub, routed by account type. An in-house enhanced due diligence service runs the questionnaires, risk scoring, and officer reviews. A compliance service holds the client's status and projects it to the services that need it.
Suitability and source of funds. Appropriateness tests with defined completion modes, a professional-client opt-up application, and proof-of-funds checks whose outcome is expressed in limits per client. Bank transfers go through payer-name verification before the trade is released.
Wallet and transaction screening. Client wallets are screened with Chainalysis. Trades and transfers are registered for transaction monitoring.
Enforced at settlement. A separate attestation signer issues a signed, time-limited authorisation for each trade only after the compliance checks pass. The contracts verify that attestation on-chain and refuse the trade without it. An ADR describes how to bound the damage if that signer were ever compromised.
Records. An activity ledger of orders and client events, built for MiFID II record keeping, and a reconciliation between that ledger and the chain. Every admin action goes through one audit stream that fails closed: if the audit record cannot be written, the action does not happen.
Every control has an ADR. Status projection, appropriateness modes, the professional opt-up, proof-of-funds bands, payer verification, the audit stream, and the activity ledger each have a written decision with the alternatives that were rejected and why.
My role
I designed the compliance architecture with the compliance team, wrote the ADRs, and built large parts of the services and the admin surface. My job was to translate each regulatory duty into a concrete system behaviour that can be tested, and to make sure no rule depends on a person remembering it.
Outcome
- Onboarding, appropriateness, and wallet screening run in production as part of the normal client flow. Hard proof-of-funds limits at order time are rolling out now.
- No primary trade settles on-chain without a valid compliance attestation.
- Officer decisions and admin changes are audited by construction.
- Compliance discussions now start from an ADR and a pull request, not from a description of how someone thinks the system works.
Tradeoffs
Fail closed costs availability. An audit stream that blocks the action when it cannot write will sometimes stop an officer from working. For a regulated firm, a missing audit record is worse than a delayed action.
Attestations add a moving part. A separate signer is one more service to run and protect. It keeps compliance logic out of the contracts, so the rules can change without a contract upgrade, and the contracts stay small enough to audit. The external review of the primary-market settlement contracts by Nethermind Security found zero issues at any severity.
Own the data model, rent the vendor. Mapping every vendor result into our own model is more work up front. It is what makes a vendor change, or a DORA exit plan, realistic.