ANSWER · SECTOR
Operational bottlenecks in BFSI: where they usually sit
Where do operational bottlenecks usually sit in banking, financial services and insurance?
In banking, financial services and insurance, operational bottlenecks usually sit at control points rather than in core processing — onboarding and KYC checks, manual exception queues, maker-checker approvals, reconciliations and claims assessment. They persist because each control exists for a regulatory reason, so the fix is redesigning how the control runs, not removing it.
Why are BFSI bottlenecks different from other industries?
In most industries, a slow step can be simplified or removed once it is found. In banking, financial services and insurance, many slow steps are controls: they exist because a regulator, an auditor or a past loss required them. Removing them is not an option, and the people who run them are rightly cautious about any change.
That makes BFSI bottlenecks unusually durable. Core processing is typically automated and fast. The constraint sits around it — in the checks, reviews and exceptions that surround each transaction — and it is protected by the legitimate argument that the check matters. The cost of getting it wrong is measured in fines, not friction.
Where do they usually sit?
Across banks, lenders, insurers and payment businesses, the same few locations recur:
- Customer onboarding and KYC. Document collection, verification and risk scoring are often split across teams and systems, with incomplete applications cycling back to the customer several times.
- Transaction monitoring and AML alert review. Screening rules tuned conservatively generate large volumes of alerts, most of which are cleared as false positives after manual investigation. The queue grows faster than the team.
- Maker-checker approvals. Dual control is essential, but when every item of every value needs the same senior checker, the checker becomes the constraint.
- Reconciliations and breaks. Mismatches between systems are resolved manually, often in spreadsheets, and the unresolved backlog ages quietly.
- Claims assessment. In insurance, the tension between cycle time and accuracy concentrates in assessment and the requests for additional information that pause a claim.
- Credit decisioning exceptions. Applications that fall outside automated rules land in a manual underwriting queue that was sized for a fraction of the volume it now receives.
Why do they not show up in reports?
Because the reports measure the controls' outcomes, not their flow. A KYC team reports how many applications it approved; it rarely reports how long applications waited between steps, or how many times the same application was touched. An alert team reports alerts closed, not the share of investigator time spent on alerts that were never going to be suspicious.
These are classic unmeasured bottlenecks — visible only as an end-to-end time that is too long, or a team that is always at capacity. The general method for finding them is in How to find an operational bottleneck you cannot measure.
How do you fix a bottleneck without weakening the control?
The principle is to redesign how the control runs, not whether it runs. In practice that tends to mean:
- Risk-tiering the control. Applying the full check to high-risk items and a lighter, still-compliant path to low-risk ones, with the tiering logic itself documented and approved.
- Fixing inputs upstream. Many exceptions are created by incomplete or inconsistent data at the start of the process. Validating at capture removes work from every downstream control.
- Removing rework loops. Asking for everything needed once, instead of discovering missing items one at a time.
- Separating the queue. Routing simple items away from the senior reviewers so that their capacity goes where judgement is genuinely required.
- Tuning rules with evidence. Using historical outcomes to adjust screening thresholds so fewer obviously benign alerts are generated, without raising the risk of missing a true positive.
Every one of these changes needs to be evidenced for the people who own the risk. That is why root-cause discipline matters so much in this sector: a change has to come with proof that it does not weaken the control.
Where does AI help in BFSI operations?
AI is most useful where the volume of manual review is high and the outcomes are recorded: alert triage, document classification, claims triage, and prioritising exception queues. It can rank which items need a person and which do not, and explain the factors behind the ranking.
The caveat is governance. Regulators expect explainability, monitoring and human accountability for automated decisions, so a model has to be introduced as a controlled change in its own right. More on the balance between the two is in Does Lean Six Sigma still work when AI handles the data analysis.
What is a sensible first step?
Pick the one control whose queue is always full, and measure the time items spend waiting in front of it compared with the time spent working on them. If the waiting time dominates, the control is a flow problem, not a capacity problem — and flow problems are usually cheaper to fix than adding headcount. Whether one hour is enough to locate it is covered in What a one-hour operations consultation can realistically deliver.
If this is the shape of your problem, one hour is usually enough to find the first move. Bring it to an hour →