Financial services
A credit file with every step reconstructable
In a lending file, the question is not only what was decided, but who saw what and on what basis. A flow held in email cannot answer the second one.
A non-bank lending institution
Where we started
The part missing from most case studies, and the only one that tells you whether it resembles your own situation.
Files travelled by email, with documents attached and decisions communicated in replies. Tracking spreadsheets existed, but they recorded the outcome, not the route. The question "who saw this document and when" had no answer that would survive an inspection, and the question "on what basis was it approved" had an answer that depended on one person's memory.
The second issue was volume. The flow worked for a few files a day. Growth would have meant more people doing the same manual work, with the same risks, multiplied.
What was breaking, concretely
- There was no complete trail of accesses and decisions.
- The documents required at each stage were checked out of habit, not by the system.
- The separation between who analyses and who approves was a matter of process, not of technology.
- The mandatory regulatory returns were assembled by hand, from several sources.
Goals
What the application had to solve
Every access and every decision should stay in a log, with an author and a timestamp.
The stages and the mandatory documents should be enforced by the system, not by personal discipline.
The separation of roles should be technical: the analyst must not be able to approve, however much they want to.
The regulatory returns should be generated from the same data rather than reassembled each time.
What we built
The application, module by module
Not a feature list, but what each piece does and why it was needed.
-
01
The case flow
The file passes through defined stages, each with its own mandatory documents and checks. It cannot advance with something missing. What used to be a checklist held in someone's head became a condition of the system.
What it covers
- Stages with mandatory documents, defined per product type
- Automated checks against the institution's criteria, with a score
- Clear states, visible to everyone involved
-
02
Strict roles and an audit log
The analyst prepares, the approver decides, the administrator configures. Permissions are enforced at the data level, not only at the screen level. Every file opened, every document viewed and every decision goes into the log, which nobody can alter from inside the application.
What it covers
- A technical separation between analysis and approval
- A complete log, not modifiable through the interface
- Visibility limited to the files that concern each person
-
03
Reports and regulatory returns
Operational reports and those needed for the mandatory returns are generated from the same data, on demand, by period. There is no longer an intermediate step where someone assembles a file from several sources and introduces their own errors along with it.
What it covers
- Reports by period, by product and by analyst
- Formats for the mandatory regulatory returns
- Complete reconstruction of a file, on demand
Decisions
What we chose and why
The choices that changed the project: where we took the simpler option, where we insisted on the more expensive one, and what would have happened otherwise.
The audit log is written separately from the working data
The simplest option would have been a history table alongside the rest. We separated the log, with different database-level permissions: the application can write to it but cannot modify or delete. A log the application can rewrite is not evidence, it is a list.
Automatic scoring, human decision
The system calculates a score against the institution's criteria and shows it clearly, with what it is made of. It does not approve on its own. That was a process choice rather than a technical one: in a field where the decision has to be owned by a person, automating it moves responsibility somewhere it cannot sit.
We built the inspection scenarios before the features
We started from the questions an inspection would ask — reconstruct this file, show who saw this document, demonstrate the analyst could not approve. We turned them into automated tests and only then built. It is the reverse of the usual order, and it is why nothing had to be rewritten at the end.
How the work looks now
No percentages and no hours saved — only what you can see by opening the application.
A file can be reconstructed in full, with all its accesses and decisions, from a single place. The stage rules no longer depend on someone's attention on a busy day.
- Every access and decision has an author and a timestamp, in a separate log.
- A file cannot advance without the documents required at its stage.
- The analyst cannot approve — it is not a procedural rule, it is a system restriction.
- The regulatory returns are generated from the working data, with no manual step in between.
What we learned
Including what we got wrong
In a regulated field, inspection requirements are not a final stage. If you do not put them in at the start, they rewrite the architecture at the end, when it is most expensive.
A log the application can modify is worth nothing at the moment it matters. Separating the write permissions was the cheapest and most valuable technical decision in the project.
Frequently asked questions
What people ask us about this project
If your question is not here, write to us — we answer just as directly.
Ask us a questionDoes the application decide approvals on its own?
No, and that was deliberate. It calculates a score against the institution's criteria and shows what it is made of, but the decision stays with a person, who owns it and stays in the log by name.
What happens during an inspection?
Any file can be reconstructed: the stages it went through, the documents at each, who saw them, when, and on what basis the decision was made. Those scenarios were written as automated tests before the features were built.
Can it be adapted for another type of financial product?
The stages, the mandatory documents and the scoring criteria are configured per product type. What does not change is the structure: a staged flow, technically separated roles and an unalterable log.
What we used from what we do
The project above happened once. These pages say what we deliver in general, who it suits and how long it takes.
Web applications
Web applications for processes an ordinary website, a CMS or an off-the-shelf product cannot cover.
Details → 4-10 weeks ServiceCode audit
A written assessment of your application: what risks exist, what remediation takes, and where it is worth starting.
Details → 1-3 weeks ServiceAngular interfaces
Interfaces for data-heavy applications, the kind people spend whole hours inside every day.
Details → 4-10 weeksOther projects
See all case studies →Leave taken out of the spreadsheet and out of the inbox
The record of leave lived in a file kept by one person, and approvals travelled by email. It worked, until two managers approved the same day in parallel.
Read →A payment notice the owner understands unaided
The manager spent more time explaining the calculation than doing it. The application did not shorten the calculation — it removed the need for the explanation.
Read →The receipt photographed on the spot, the claim closed without the pile
Receipts collected in a wallet and reached accounting once a month, creased and without context. Half the time spent on claims went into reconstructing who spent what, where and why.
Read →Do you recognise anything in the situation above?
Tell us how you work today and where it gets stuck. The first conversation is about you, not about what we did for someone else.