AI onboarding and KYB automation in the UAE
Every file reaches approval complete, and the first order stops waiting on the one document nobody chased.
The trade licence, the ownership chain, the board resolution and the bank letter are read as they arrive and checked against what your own policy requires for this counterparty and this jurisdiction. What is missing is named and chased while the file is still open, and anything the policy does not settle stops at the person who signs, with the reason attached.
Four jobs an onboarding desk repeats.
The counterparty file
From pack to approval, without the wait nobody can account for.
A new counterparty arrives as a pile: the trade licence, the ownership chain up to the people who actually own it, the board resolution, the bank letter and whatever this jurisdiction adds on top. Each document is read and checked against your own rules for this counterparty type, and what is missing is named at the start rather than discovered at the end.
Screening and periodic review
Runs on the schedule the file is due, not on someone remembering.
Names, owners and jurisdictions are checked against the lists you already use, and the same check runs again when the file comes round. A hit arrives attached to the file it belongs to, with the history and the last decision beside it, so the person deciding is reading a case instead of assembling one.
The regulator file
Current on the day it is asked for, not rebuilt for the request.
The evidence behind every approval, every exception and every review is written into one file as the work happens, each answer pointing at the document it came from. When the request lands, what you send is what you already had.
The exception that stops the file
Decided by a person, with everything already gathered.
Most files clear on the policy as written. The ones that do not stop at a named person, with the reason, the document and what was decided the last time this came up already on the screen, and the disposition is written back into the file.
Onboarding software ends at the checklist.
It collects the documents and still waits for someone to judge whether what came back is good enough. Runbook arrives knowing your business, because writing down how you actually approve a counterparty is where we start.
You own it. No seat bill.
It runs in your cloud account. If you stop paying us, it keeps running. What stops is us watching it, fixing it and extending it.
How the work runs.
The audit
We sit with the people who make the calls and read everything they read, including the exceptions that are not written down anywhere. You get the work mapped, the jobs ranked worth programming and not, and the value case in your own numbers.
The build
The data layer first, then the agents on top of it. It ends in production, inside the systems your team already opens, not in a pilot.
The run
We watch it and extend it as the work changes. Failures reach us before they reach you.
You leave the first meeting with a one-page sketch of the job you brought.
Questions the people who approve counterparties ask.
Does this decide who we take on?
The system does not decide who you take on. Your policy stays yours and the approval stays with the person who signs it: the system gathers the file, checks it against the rules you already apply, and presents what is complete and what is not. Anything the policy does not settle stops at a named person with the reason and the evidence attached.
We already have a screening provider. Where does this sit?
It sits around what you already have. Your provider keeps doing the check it does well, and Runbook does the part between the checks: collecting the pack, reading what actually arrived, putting the result next to the file it belongs to, and carrying the outcome into every system that needs it. Nothing is ripped out to make room for it.
Every counterparty is different. How can this be programmed?
Counterparties differ in judgment, not in assembly. What a counterparty of this type in this jurisdiction has to produce is written down once, and after that the gathering, the checking and the chasing run the same way every time. That is what makes the unusual file visible instead of buried among the ordinary ones.
What happens when a document is missing or unreadable?
It is named as missing and chased on its own, without anyone having to remember to. A scan nobody can read, an ownership chain that stops at another company, a certificate that arrives as a photograph of a screen: those are the inputs the work is built around, and the ones that cannot be resolved stop at a person rather than being guessed.
How long does it take?
The scope, the fee and the finish date are agreed with you in writing before anything starts. We do not publish a length, because it follows the size of the operation, how many systems the work touches and what condition the data is in.
Who owns it when you leave?
You do. The code, the credentials and the documentation sit in your accounts and under your name from the day we start. It runs in your cloud account, and if you stop paying us it keeps running.
What does the first meeting cost?
Nothing. It is forty five minutes, and you leave with a one-page sketch of the job you brought: the steps as they run today, where the line would sit, and what we would measure.
Can we show how a file was approved, long after the fact?
Yes. Every check, every exception, every review and every approval is recorded against the file as it happens, with the document each answer came from. When someone asks for the history, it is retrieved rather than reconstructed.