Financial services
The sector we start in, and the one where the founders' own systems have already answered to auditors, security reviewers and the people who run payment rails.
Financial services is the first sector Caltor works in, by choice. Banks, payments companies, insurers and fintechs rarely lose an AI programme on the model. They lose it on evidence: what the system decided, who approved it, where the data sat, and whether any of that survives review. The evidence problem is an engineering problem, and it is the one the founders have spent their careers solving.
What model risk governance asks of a system
In this sector a model is not a component, it is a controlled object. Someone has to describe what it does, what it was tested against, how it behaves at the edges, and who signed it off. We design for that from the first architecture. Every decision the system takes is recorded with the inputs that produced it, the model and prompt version behind it, and a plain-language reason a reviewer can read without opening a notebook. Explainability bolted on afterwards is reconstruction, and reviewers can tell the difference.
Where the data sits, and who can reach it
Residency and segregation are architecture decisions and they are painful to retrofit. We work inside your cloud accounts and identity systems rather than copying data out, keep entity and tenant boundaries explicit in the data layer, and design retrieval so a model can only reach documents the requesting user is already entitled to see. Where an obligation constrains a region, a processor or a storage boundary, that constraint is written into the design rather than managed by policy around it. The founders built multi-tenant platforms with strict per-tenant isolation, and that habit carries into every estate we design.
Change control in a regulated estate
Financial institutions do not accept a system that changes underneath them. Model, prompt and retrieval changes ship the way code ships: versioned, tested against an evaluation suite, reviewed, and released through your own change process with the previous version recoverable. Environments stay separated, every release is traceable to an approver, and nothing reaches production because it looked better in a demo. This is the least glamorous part of the work, and it is the part that decides whether a system is still trusted after its first incident.
The systems it has to live inside
AI in this sector is judged on integration. The work touches core banking and policy administration, payment rails and ledgers, CRM and servicing platforms, data warehouses, and the reporting that examiners eventually read. We design against the estate you actually run, including the parts nobody wants to touch, and we prefer a boundary the incumbent system can defend over a rewrite it cannot. Where a system of record must stay the system of record, the AI reads and proposes while the write path stays inside the controls you already have.
Third-party review, and the evidence we bring to it
Engaging a firm this size means putting us through vendor and third-party risk review, and we expect it. We complete the questionnaire ourselves, take your security team through the architecture, and accept the controls your programme requires of any supplier. What we point to is our own work rather than client logos we do not have. Pays, a founder-built payments venture, was designed so that every payment is bound to an auditable spend policy from the first line of its architecture. Redwipe, the founders' security platform, reports against SOC 2, ISO 27001, HIPAA and PCI-DSS.
What we build in financial services
- Retrieval over regulated material such as policies, filings, contracts and procedures, where every answer cites the source it came from and respects what the reader is entitled to see.
- Decision support for credit, underwriting, servicing and operations, built so each recommendation carries its inputs, its model version and a reason a reviewer can read.
- Agents that execute finance and payment workflows under explicit limits, with a human approval step and an auditable record of every action taken.
- Integration layers between AI systems and core banking, payment, ledger and CRM platforms, designed so the system of record keeps the controls it already has.
- Evaluation suites and monitoring that catch model, prompt and content drift before a customer or an examiner does.
- Documentation written for model risk, security and audit review: architecture, data flows, controls and test evidence, produced as a deliverable rather than assembled under pressure.
What this is not
This is not a regulatory or legal service. Caltor does not issue compliance opinions, certify a system against a framework, or act as your independent model validation function, and nothing here is a claim to stand between you and your regulator. We build systems your risk, audit and security functions can inspect, and we hand those functions the evidence they need to do their own work.
Talk to a partner
If there is a use case in your book that stalls every time it reaches model risk, security or audit, describe it and a founding partner will tell you how we would build it and where the evidence would come from.
