Industry
AI employees in fintech
Tobiloba Odejinmi · 14 Jan 2026 · 6 min · 974 words
Direct answer
An AI employee in fintech only works if the rails underneath it are boring. At Zeeh Africa, adoption grew 890% in nine months because banks and lenders could connect in a day, not a quarter. Put the employee on those APIs: first-pass KYC, failed-connection tickets, reconciliation. If it needs a new portal and a three-week workshop, it will die in procurement.
- Time-to-first-call is the product. The employee inherits that test.
- 390+ companies do not integrate because of a keynote. They integrate because it is dull and documented.
- Use the employee on support, first-pass checks, and the pile of failed jobs. Not on silent money movement.
- If setup takes a project plan, you still have work to do.
Before lunch, or not at all
I ran a team of eight at Zeeh Africa. The work that paid off was not a new metaphor for banking. It was making identity and account data something another team could call without a three-week workshop.
When I talk about AI employees in fintech now, I use the same test. If it needs a new login and a new religion, it will die in procurement. Banks will use you if they can plug in before lunch. Clever ones wait for a champion who never gets budget.
What the employee is for
Fintech teams already have a pile. Connection errors. KYC files that are almost complete. Support threads that are the same screenshot, again. Reconciliation rows that do not match. That is the job.
The employee looks up the account, writes the first note, and flags the ones that need a person. It does not invent a balance. It does not 'fix' a ledger because the model felt sure.
- First-pass KYC: pull the fields, list the gaps, stop before the decision.
- Support: the failed-connection ticket your team already answers by heart.
- Reconciliation: draft the mismatch, leave the posting to a human.
- Onboarding: walk a new company to first successful call without a Slack thread that lasts a week.
Boring APIs are the platform
Three hundred and ninety companies do not stay because you were interesting in a demo. They stay because the endpoint did the same thing on Tuesday that it did on Monday. An AI employee that wraps a flaky API just creates faster confusion.
Make the API boring first. Document the errors. Return a shape another system can check. Then attach the employee. The other way around is how you get a clever assistant nobody can put in production.
The book has to stay explainable
In the Zeeh era, non-performing loans on the books that used those rails stayed under 5%. I do not treat that as a model win. I treat it as what happens when the data coming in is clean enough for a person to underwrite.
If your AI employee starts filling gaps with guesses, you will not keep a number like that. You will get a week of speed and a quarter of arguing with a risk team about where the fiction entered the file.
Cost, uptime, logs
A bank partner will not open your vision deck first. They will ask what it costs to run, how often it breaks, and who can change it without you in the room. Fancy slides do not survive that meeting if the logs are a mess.
Give the employee an owner. Write down what happens when it is wrong. Keep a switch. If only one engineer understands the workflow, that is a risk, not a flex.
Start with one process
Pick the ticket type that burns the most hours. Map the steps. Connect to the tools the ops team already has open. Hand it over with monitoring and a write-up someone else can follow.
If the first call still takes a project plan, you still have work to do. Do that work before you hire a metaphor.
I have watched teams buy a 'digital worker' and then spend a quarter getting it permission to see the same endpoint a junior engineer called on day one. That is not an AI problem. That is an integration problem you already knew how to solve.
What I would not automate
I would not let an employee post a ledger entry. I would not let it change a limit. I would not let it send a regulatory notice because the prompt sounded formal. Those are named jobs with named people.
The employee can draft the reconciliation and open the ticket. It can walk a new company to first successful call. It can answer the screenshot your support team has answered two hundred times. That is enough work for a first week. It is also the work that actually ships.
Questions people ask
What grew at Zeeh, and why does it matter for AI employees?
Adoption grew 890% in nine months. Banks and lenders plugged in through APIs used by 390+ companies. An AI employee sitting on a connection that takes a quarter will never see that kind of use.
Should the employee move money on its own?
No. It can draft the reconciliation, flag the mismatch, and open the ticket. A person still owns the ledger. I have sat on systems where a wrong row meant someone did not get paid.
What do banks actually want?
A boring API, an audit log, and a way to turn you off. They do not want a new metaphor for banking. They want to plug in before lunch.
Where should a fintech start?
The tickets you already answer about failed connections, missing fields, and 'why is this account not returning data'. That pile is the product.
How does credit quality fit this?
In the Zeeh era the books that sat on those rails stayed under 5% NPL. Clean identity and account data is not a slogan. It is how a lender still has a book they can explain.
Written by
Tobiloba Odejinmi
Head of Engineering at 10mg Health. I have run engineering at Zeeh Africa and sold Insurpass and Shopl. I still write the code. If you have one process that still runs on people copying things, we can look at it in thirty minutes.
