// Fintech
AI Automations for Regulated Finance Operations
Sending a customer record to a model vendor is a transfer of financial data to a third party in some country. The automation has to slot into controls your firm already operates. So the first design question is which steps may see the data at all, and the answer keeps the model out of the decision.
What changes in Fintech
- A hosted model sends customer financial data to a vendor in a region, so both are design inputs and some steps need a self-hosted model
- An approval screen is a control only if the person clicking already holds that authority, so the workflow uses existing sign-off, inventing no new approver
- Months later someone can ask why a case was decided that way, so run records keep the model version and exact input longer than logs
- A repeated write into a ledger or payments queue is a money event, so idempotency goes in the first build, never a later hardening pass
- Where an outcome changes what a customer can access, the decision stays in readable code and the model only assembles the material for it
The workflows are the same ones on the parent page. Intake, extraction, reconciliation, first drafts, watching a queue. What is different in a regulated finance business is that three of the design decisions are made for you before anyone opens an editor.
Decide what the vendor is allowed to see
Every call to a hosted model is a transfer. Whatever you put in the prompt goes to a company in a country, under that company’s retention terms. That is a data question with an owner in your business and it gets answered first, per workflow, per field.
The answers vary more than people expect. A document classifier can often run on a redacted page, because the model needs the shape and not the account number. A reconciliation step frequently needs no model at all once somebody looks at the matching rules. A summariser working on complaint correspondence may end up on a model you host, because the content cannot leave your own estate. We work through that list in scoping and write the result into the design, so nobody discovers the constraint after a build.
The approver already exists
The obvious move is to build an approval screen inside the new tool. In your firm that approval already exists, held by a named role with a documented limit. A new queue in a new tool is not that control. It is a second one, competing with the first.
So the workflow slots into what is there. Where a case already goes to a four-eyes check, the automation prepares it and sends it to the same place. The material a reviewer needs is attached. What was extracted, from which document, what the automation would do, and the confidence behind it. Where the existing tooling has a queue, we write into that queue. Where no control exists for an action, we say so. Building an approval step for an action nobody was authorised to take is a compliance problem we would be creating for you.
Make one run reproducible three years later
A logging line saying the workflow classified a case as high risk is worth very little. The question that arrives later is why. Answering it needs the input as it was received, and the model and exact version that saw it. Then the prompt revision, the raw output, the deterministic rules applied afterwards, and the person who approved it and when.
Two things follow. Model versions get pinned, because a vendor quietly moving you to a newer one changes behaviour you have evidence about. And when a version is retired, the evaluation set runs against its replacement before the switch, with the differences written down. Evaluation cases come from your own closed records, which is what makes the first release an argument backed by numbers.
Keep the model out of the decision
Where an outcome affects what a customer can borrow, open or access, the decision belongs to code somebody can read line by line. The model’s job stops at preparing the material. Pulling figures out of a statement, matching a name against a document, summarising twelve months of correspondence. Flagging the cases a person should look at first.
That split is worth the small amount of extra engineering it costs. A deterministic rule can be explained to a customer, tested in CI, and reproduced exactly on the day someone asks. A model output attached as evidence, with the document it came from, is still useful to the person deciding.
Money moves once
A retry that sends the same payment instruction twice is not a bug you write a ticket for. Every write into a ledger, a payments queue or a core banking system carries an idempotency token derived from the case. Retries are tested against a stub that deliberately duplicates. The reconciliation that would catch a double write runs from day one, and alerts a human.
Shadow mode matters more here than anywhere. The workflow runs beside your team on live cases, with its output compared against what the person actually did. Nothing it produces reaches a customer or a ledger until two things hold. The disagreement rate is known, and someone senior has read the disagreements themselves.
This is the Fintech view of AI Automations. That page covers how the work runs whatever the sector.