We build software for the processes your regulator audits.
For banks, insurers, healthcare providers and other licensed businesses. We start from the rules you must meet and the evidence an auditor will ask for.
What an audit asks of your software
An audit asks four things of a record: what happened, who did it, when, and whether anyone could have changed it afterwards. Most business software answers the first three poorly and the fourth not at all. Spreadsheets, email approvals and shared logins fill the gap, and those are what an auditor finds.
So we write each rule down beside the record that proves it and the report that shows it. The build is finished when every line in that register passes its test.
What you get
Obligations register
Every rule the system must meet, with the record that proves it and the test that checks it.
Append-only audit trail
Every change to a regulated record, with user, time and old and new values. No screen or API can edit or delete an entry.
Reports with their workings
Reports in the regulator's format. Each figure traces to a saved query, so you can reproduce any past figure.
Access model and retention schedule
Roles, approval steps and segregation of duties, enforced in code. Each record type has a retention period and a log showing the rule ran.
Evidence pack
Test results, the access matrix, the register and the change log, ready to hand to an auditor.
When this service fits
Choose this service when a regulator, an auditor or a licence condition dictates what your software must record and report. It fits when an audit finding names a system, or when regulated work still runs on spreadsheets.
It is the wrong choice if you need someone to tell you what the rules mean. We are engineers, not lawyers. Your compliance officer interprets the regulation and we build to that reading. If an established product covers the requirement, buy it.
How the work runs
List the obligations
In the 1-week discovery we write the register with your compliance lead: each rule, its record, its report and its deadline.
Design for evidence
We design the data model, audit trail and access matrix before any screen. Each decision points to a line in the register.
Build with hostile tests
Increments ship to staging every 2 weeks. The tests try what an auditor fears: editing a log entry, approving your own transaction, reading outside your role.
Walk through, then go live
Your compliance or internal audit team checks the system against the register. We fix what they find, then hand over the evidence pack.
A typical engagement
- Discovery
- 1 week, ends with specification and obligations register
- Build length
- 10 to 20 weeks for a first release
- Audit trail
- Append-only, searchable without a developer
- Handed over
- Repository, tests, evidence pack, documentation, credentials
- After go-live
- 30 days of defect fixes at no charge
Questions buyers ask
Do you certify that we are compliant?
No. That judgement belongs to your regulator and your compliance officer. We build to the register you signed and give you evidence that the system matches it.
Where is our data hosted?
In accounts you own. The specification names the hosting location, so rules on where data may sit are settled before we build. You grant our access and can remove it.
What happens when the regulation changes?
The register shows which parts of the system a rule touches, so the change is quick to scope. After go-live, a maintenance agreement can cover it.
Related pages
Article: what an audit trail has to record
What an auditor expects in every log entry, and why.
Industries
The regulated sectors we build for and what each one needs.
Integration service
For filing to government and bank portals.
Tell us which process is audited and we reply within 2 working days.
Start a project