Monday's queue is longer than Friday's
A marketing push went out on Thursday. Sign-ups jumped, and so did the number of applicants who did not pass straight through your identity and verification checks. By Monday morning the ops team has a queue of referred cases, and each one sits behind a status in the app that says something like 'we are just checking a few details'.
Your analyst opens the first case. The identity result is in one provider's dashboard, the document images in another, the address check in a third, and the device and email signals in whatever your fraud tool shows. The customer's own answers are in your admin panel or, worse, in a database table an engineer has to query. The analyst copies the reference number from tab to tab, reads, decides, then goes back to the admin panel to click approve and leaves a note in a spreadsheet so the team lead can see it was done.
Meanwhile the customer has emailed support twice, and the support agent can see the account is pending but not why.
The checks are not the slow part
Most onboarding providers return a result quickly. The slow part is everything around a referral. Nobody designed the review step; it grew out of the first few weeks when founders did the reviews themselves and a handful of cases a day was fine.
- Results live in separate vendor dashboards with no shared case view.
- Referral reasons are not labelled, so a name mismatch and a blurry document land in the same pile.
- The decision is recorded in more than one place, so there is no single answer to 'who approved this and on what basis'.
- Requests for more information go out by hand from a shared inbox, and the reply is not attached to the case.
- Nobody sees queue age, so the oldest case is not always the next one picked.
Your own rules decide who needs a closer look. The problem we deal with is the plumbing between those rules and a person making a decision.
What a slow queue costs a young fintech
The obvious cost is analyst time spent switching tabs. The larger one is customers who drop out while pending and never come back, which makes your acquisition spend look worse than it is. Support gets tickets it cannot answer. Engineers get pulled in to run queries or unstick accounts, which is time off the roadmap.
There is a quieter cost too. When your partner bank or a provider asks how a particular customer was approved, the answer is spread across screenshots, a spreadsheet row and someone's memory.
The review console we build
What we build sits alongside the providers you already use. We do not replace your checks or your rules.
- Webhooks and API calls from each check provider feed one case record per applicant, keyed on your customer ID.
- Each referral gets a reason label from the provider's result codes, so the queue can be split into document issues, data mismatches and anything your rules send for a fuller review.
- The analyst sees one screen: the applicant's answers, every check result, document images, prior notes and similar past cases.
- Requests for more information are sent from the case using templates you write, and the customer's upload lands back on the same case.
- The decision button writes the outcome to your core system through its API, with the analyst's name, time, reason and any note.
- Queue age, volume by reason and cases waiting on the customer are shown to the team lead.
| Referral reason | Where it goes | What the analyst sees first |
|---|---|---|
| Document unreadable or expired | Document queue | The image, the provider's reason code, a one-click re-request |
| Name or date of birth mismatch | Data mismatch queue | Both values side by side with the source of each |
| Address not verified | Data mismatch queue | The address given and what the check returned |
| Rule-based referral from your policy | Senior review queue | Every result plus the rule that fired |
| Waiting on the customer | Parked, with a reminder date | What was asked and when |
If you want it, an AI model such as Anthropic Claude or OpenAI can draft a short summary of the case for the analyst. It is labelled as a summary, and the analyst still decides.
A normal Monday with the console in place
The team lead opens the queue and sees it split by reason, oldest first. Document re-requests went out automatically over the weekend, so some cases have already come back with a fresh upload. Analysts work one screen per case, and a decision takes a click and a reason from a list you control.
Support can see the plain-language status and what the customer has been asked for, so the 'where is my account' ticket gets a real answer. When a partner asks how a customer was onboarded, the case record shows every result, every message and the decision in order.
Signs your onboarding review has outgrown its setup
- Analysts open three or more dashboards to review one applicant.
- Decisions are logged in a spreadsheet as well as your admin panel.
- Engineers get asked to look up or unstick pending accounts.
- Support cannot tell a customer why they are pending.
- Nobody can say how old the oldest case in the queue is.