Industries We Build Software For

What regulated delivery has in common

Banking, healthcare and government look like three different problems. In engineering terms they are largely one problem wearing three regulators. The specific obligations differ; the structural demands they place on a system are close to identical, and a team that has genuinely internalised them in one sector transfers to another far better than sector-specific marketing suggests.

You are building for an examiner, not only for a user

This is the reframing that changes the most decisions. A conventional system is designed so that users can accomplish tasks. A regulated system carries a second audience who will arrive later, ask what happened months ago, and expect the system to answer with evidence.

Practically that means current state is not sufficient. You must be able to reconstruct what the system knew at the moment a decision was taken: which rules were active, which thresholds applied, which version of a policy was in force, and who approved the configuration that produced the outcome. Systems that store only the latest value can answer “what is true now” and cannot answer “why did you do that in March”, and the second question is the one that gets asked.

The audit trail is a feature, with a budget

Audit logging is routinely treated as infrastructure: something added late, sized casually, and never tested against a real retrieval scenario. In regulated delivery it is a primary feature with its own data model, retention policy, access controls and performance characteristics.

Two properties matter more than completeness. It must be append-only, because an audit trail that can be edited by the system that writes it evidences nothing. And it must be queryable along the axis an investigation actually uses, by subject and by time, rather than only as a chronological stream you have to grep. Retrofitting either property onto a live system with years of history is among the more painful pieces of work we get asked to do.

Identity is a risk decision, not a boolean

Every sector here has to establish who someone is before granting them anything: a bank onboarding a customer, a hospital releasing a record, a government portal issuing an entitlement. The failure mode is identical too: teams build the happy path and discover it covers perhaps seventy per cent of real traffic.

The architecture that survives contact with reality treats verification as graded evidence feeding a risk decision, with defined assurance tiers and a documented route between them, instead of a single gate that a legitimate person can fail with nowhere to go. The design detail is in our guide to CNIC and biometric verification.

Interoperability is a schema you do not control

Regulated sectors are defined by mandatory external interfaces. A financial institution reports to its intelligence unit on that unit's schema. A hospital exchanges records under HL7 FHIR. A government platform integrates with national identity and revenue infrastructure on terms it does not set.

The common engineering error is treating these as export formats: build the internal model, map at the boundary. That holds until the external schema requires something the internal model has no room for, at which point it is retrofitted under deadline. Let the mandatory interface inform the domain model from the start. The same reasoning appears in both our HL7 FHIR and goAML write-ups, because it is the same lesson.

Availability obligations are asymmetric

Consumer software treats downtime as lost revenue. In these sectors an outage can be a reportable event, a clinical safety issue, or a citizen unable to access an entitlement with a statutory deadline attached. The cost is not symmetric with the traffic, and capacity planning that reasons only from average load will get this wrong.

It also changes how you deploy. Release processes that assume you can push a fix forward quickly are a poor fit where a change to a regulated calculation may itself require notification. Design for the constraint that rollback, not roll-forward, is your primary recovery path.

Data minimisation is protective, not restrictive

Teams new to these sectors treat retention limits as an obstacle. The better framing is that data you do not hold cannot be breached, subpoenaed, or mishandled by a future integration nobody has designed yet. Biometric templates are the clearest case: permanently identifying, impossible to reissue after a compromise, and unnecessary to retain once a check has completed.

Design to the strict end of whatever regime applies. It is defensible under any likely change in the rules, and it is what enterprise and government procurement asks for regardless of what the statute currently requires.