Regulated delivery
Compliance built into the system.
Not bolted on at the end.
We build crypto and fintech products for licensed teams. MiCA, PSD2, AML and GDPR duties shape the architecture from day one. That means fewer surprises at audit. It also means a shorter path to launch.
Our clients are VASPs, PSPs, EMIs, neobanks and crypto startups across the EU. They need one partner who understands both the chain and the rulebook.
Frameworks
The rulebooks we design against
Each framework changes concrete parts of the build. Here is where it lands in the code, the data model and the run book.
-
MiCA
Markets in Crypto-Assets
We map licence duties onto the system early. Safeguarding, disclosure and reporting land as real services, not slides.
MiCA-ready architecture
-
PSD2
Payment services
Strong customer authentication, SCA exemptions and clean audit trails. Payment flows carry their own evidence.
Payment rails
-
AML
AML & Travel Rule
Screening, risk scoring and Travel Rule messaging sit inside the transaction path. Nothing runs as a side script.
AML / Travel Rule aware
-
GDPR
Data protection
EU data residency, least-privilege access and retention rules. Personal data is scoped before the first schema is drawn.
GDPR-compliant delivery
-
PCI
Card data readiness
Card flows stay outside your core where possible. Scope shrinks, and the yearly review gets far cheaper.
PCI DSS readiness
-
SOC 2
Control readiness
Change control, logging and access reviews ship with the build. Your auditor reads systems, not promises.
SOC 2 readiness
Control surface
Controls that leave a trail
A control nobody can prove is not a control. So each one ships with the record that shows it ran. Auditors read the system, not a deck.
The table lists the baseline we apply to digital-asset builds. Scope changes by licence and product. Read the deeper build detail on our compliance engineering and wallet and custody pages.
| # | Area | Control | Evidence |
|---|---|---|---|
| 01 | Key custody | MPC or HSM signing, split quorum | Key ceremony record, rotation log |
| 02 | Transaction screening | Pre-broadcast checks with hard stops | Decision trail per transfer |
| 03 | Client funds | Segregated ledgers, daily reconciliation | Break report, sign-off history |
| 04 | Access | Role-based, reviewed each quarter | Access review export |
| 05 | Change control | Reviewed merges, signed releases | Release record per deploy |
| 06 | Incidents | Severity tiers, agreed response windows | Written post-mortem |
Method
Four gates, one delivery discipline
Compliance work is scheduled, not improvised. Every phase has an owner and a written output.
-
01
Obligation baseline
Discovery names your licence path and duties. We write down what applies before any code is planned.
-
02
Architecture gate
Each duty becomes a control in the design. A threat model and data map go with it.
-
03
Build with evidence
Controls ship inside the product. Logs, records and reports are features, not later clean-up work.
-
04
Hardening and handover
We test the controls, then hand over runbooks. Your team can answer an auditor without us.
Questions
What teams ask us first
Straight answers about scope, change and existing systems.
Do you provide legal or licensing advice?
No. We are engineers, not a law firm. We build what your counsel and compliance officer define. We translate those duties into architecture, controls and evidence your regulator can read.
What happens when the rules change mid-build?
Duties are re-checked at every phase gate. Most changes land as a scoped adjustment inside the roadmap you already approved. When a change moves the build envelope, you get the impact in writing first.
Can you work with our existing platform?
Yes. Most engagements start with a system that already exists. We read the current design, find the gaps, then close them against interfaces your team owns.
Bring us your compliance surface
Send the licence path and the product you plan to ship. We come back with the architecture, the control gaps and a delivery order. Architects join the call. An NDA comes first.