Building software for a regulated industry is not harder than building for an unregulated one — it is different. The code is similar. The architecture is similar. What changes is the set of constraints the product must satisfy before it can legally operate. Those constraints affect cost (+30–60% vs unregulated), timeline (+4–8 weeks), and architecture (audit trails, encryption, role-based access, data residency). If you plan for compliance from day one, it is manageable. If you bolt it on later, it is expensive and sometimes impossible.
This article covers what changes when building for fintech, healthtech, and edtech — the three regulated verticals we see most often.
What all regulated industries share
Regardless of the specific vertical, regulated software must handle:
- Audit trails. Every significant action is logged with who did it, when, and what changed. Logs are immutable — nobody can alter or delete them.
- Data encryption. At rest and in transit. AES-256 for storage, TLS 1.2+ for transport. No exceptions.
- Role-based access control (RBAC). Users see only the data and functions they are authorised to access. Admin, manager, operator, viewer — each with defined permissions.
- Data residency. Data must be stored in specific geographic regions. EU data stays in the EU. Some sectors require country-specific storage.
- Incident response. A documented plan for data breaches, including notification timelines (72 hours under GDPR). For the full GDPR framework, see GDPR for custom software.
Fintech: what changes
Key regulations: PSD2 (Payment Services Directive), AML (Anti-Money Laundering), KYC (Know Your Customer), MiFID II (for investment services), GDPR.
What this means for the product:
- Identity verification (KYC). Users must be verified before certain transactions. This typically requires integration with a third-party KYC provider (Onfido, Jumio, Sumsub). Budget €2,000–€5,000 for the integration + ongoing per-verification costs.
- Transaction monitoring (AML). The system must flag suspicious transactions based on predefined rules. This requires a rules engine or an AI classifier, plus a compliance dashboard for manual review.
- Licensing. Depending on what the product does (payments, lending, investment), you may need a licence from the national financial regulator. In Croatia, that is the CNB (Croatian National Bank) or HANFA. Licensing can take 6–18 months and cost €20,000–€100,000+ in legal fees.
- Strong Customer Authentication (SCA). PSD2 requires two-factor authentication for electronic payments. Plan for this in the auth architecture.
Cost impact: +40–60% on top of the base development cost. A fintech MVP that would cost €30,000 unregulated typically costs €45,000–€50,000 with compliance built in.
Healthtech: what changes
Key regulations: GDPR (health data is a special category), MDR (Medical Device Regulation — if the software qualifies as a medical device), national health data laws.
What this means for the product:
- Health data handling. GDPR classifies health data as a “special category” requiring explicit consent, stricter access controls, and data protection impact assessments (DPIA). You cannot treat health data like regular personal data.
- Medical device classification. If the software provides diagnostic recommendations, treatment suggestions, or clinical decision support, it may be classified as a medical device under MDR. This triggers CE marking, which costs €30,000–€100,000 and takes 6–12 months. If your product is operational (scheduling, billing, records management), MDR likely does not apply.
- Data residency and access. Health data often must stay within the country or the EU. Access must be traceable — who viewed which patient record, when, and why.
- Interoperability. Health IT systems are expected to exchange data using standards like HL7 FHIR. If you are integrating with hospitals or clinics, FHIR support is increasingly mandatory.
Cost impact: +30–50% for operational health software. +100–200% if MDR applies (due to certification costs, not development costs).
Edtech: what changes
Key regulations: GDPR (especially for minors), national education data laws, accessibility standards (WCAG 2.1 AA or EN 301 549 in the EU).
What this means for the product:
- Data protection for minors. If users are under 16 (or under 13 in some jurisdictions), parental consent is required for data collection. The consent flow must be verifiable, not just a checkbox.
- Accessibility. Educational software in the EU must meet WCAG 2.1 AA standards. This affects UI design, colour contrast, keyboard navigation, and screen reader compatibility. Accessibility is not optional — it is a legal requirement.
- Content moderation. If users can generate or share content (forums, chat, file uploads), the platform must have moderation capabilities to protect minors.
- Data minimisation. Collect only the data you need. Education platforms have a tendency to track everything “for analytics” — in a regulated context, every data point collected must be justified.
Cost impact: +20–40% for accessibility compliance (affects design and frontend development significantly). Data protection for minors adds €2,000–€5,000 for the consent flow architecture.
How regulation affects architecture
| Requirement | Architectural impact |
|---|---|
| Audit trails | Event sourcing or append-only logs; separate audit database |
| Encryption at rest | Database-level or field-level encryption; key management system |
| RBAC | Permission system baked into the backend from day one |
| Data residency | Region-specific infrastructure (EU cloud providers or EU regions of AWS/GCP/Azure) |
| Incident response | Monitoring, alerting, and automated notification workflows |
| Accessibility | Component library chosen for WCAG compliance; testing integrated into QA |
The critical point: these must be designed into the architecture from the start. Adding audit trails to a system that was not built for them requires rearchitecting the data layer — which is essentially a rebuild.
The compliance-first approach
We recommend building compliance into the foundation, not bolting it on:
- Discovery includes compliance mapping. During the Discovery sprint, we identify every regulatory requirement that applies and design the architecture to satisfy them.
- Compliance is a first-class feature. Audit trails, encryption, and RBAC are in sprint one, not sprint ten.
- Legal review happens before development. The regulatory landscape is reviewed with a lawyer before the first line of code, not after launch.
Frequently asked questions
Can I build an MVP and add compliance later? For some requirements (accessibility, consent flows), yes — but plan for the cost. For others (data encryption, audit trails), no — retrofitting is harder than building correctly. We advise building the compliance foundation into the MVP.
Do I need a lawyer for this? Yes. A technology lawyer familiar with your specific vertical costs €150–€300/hour and saves you from expensive mistakes. Budget €3,000–€8,000 for a legal review of the product spec.
Is regulation the same across the EU? GDPR is EU-wide. Sector-specific regulations (fintech licensing, health data, education) vary by country. Always check the national requirements for your target market.
Related articles
- Got an idea for vertical software? How to validate it — Validation for regulated verticals.
- GDPR for custom software — The full GDPR compliance checklist.
- From industry expertise to software product — The founder playbook that applies to regulated industries too.
Building for a regulated industry?
Book a free 30-minute call. We will identify the regulatory requirements for your specific vertical, estimate the compliance cost, and help you plan a build that is compliant from day one.
Reach out at [email protected] or via the form on our homepage.