Bad processes cost organisations up to 30% of annual revenue. In a lending bank, that waste rarely shows up as failed transactions or missed policy thresholds. It shows up as approval latency: days accumulated at handoff boundaries, not hours spent making credit decisions.
Your approvers are not slow. Your routing is. An experienced credit analyst in Singapore or Malaysia reaches a judgment in under 30 minutes. The days between application receipt and offer dispatch pile up at boundary moments — business development to credit, credit to risk, risk to documentation. Each boundary is a handoff. Each handoff is a point where files queue, context fragments, and senior-approver time disappears into work that should not have reached that approver at all.
This post maps those boundary moments, explains which ones to remove versus redesign, and shows how the E-S-S-A-M framework — Eliminate, Simplify & Standardize, Automate, Migrate — applies to the decision spine of a credit workflow. The Migrate phase receives the most attention here, because it is the phase that directly reclaims the scarcest capacity in a lending bank.
Approval latency is a leading indicator, not a lagging metric
Most banks measure credit cycle time in aggregate: application received to offer issued, expressed in days. That number is a lagging metric. It confirms what already happened. It cannot tell you where the problem concentrates or which handoff to address first.
A leading indicator approach treats each boundary transition as a measurable unit. Business-to-credit wait. Credit-to-risk wait. Risk-to-documents wait. Summing those waits against actual processing time produces the process efficiency ratio. In most unmapped credit workflows, the ratio is stark: active processing represents a fraction of elapsed calendar time. The remainder is idle time distributed across handoffs that no one has formally measured.
Abdulla Al-Awadi, founder of ESSAM and former chief strategy officer at a Kuwait bank, observed this pattern repeatedly when mapping approval workflows. The apparent complexity dissolved once handoffs were isolated. Three recurring patterns appeared: sequential routing where parallel routing was safe, manual notification steps where automated alerts were available, and senior-approver queues loaded with files that did not require senior judgment.
Those three patterns are the intervention targets.
The decision spine: four segments, four boundary risks
A credit approval workflow has four segments connected by three boundary transitions.
Business development to credit. Application received, packaged, and transferred to credit analysts. This transition is frequently the longest single delay in the workflow — not because credit analysts are slow to start, but because files arrive in batches, incomplete, or both. Without a completeness gate at this boundary, analysts spend time chasing documents rather than analysing credit.
Credit to risk. Credit assessment complete; file escalated for independent risk review. This boundary stalls when risk reviewers lack context and request supplementary information from credit, creating a rework loop that sends files back upstream.
Risk to documentation. Approval conditions confirmed; documentation team notified to prepare offer letters. This transition introduces a new queue, a new team, and a separate system. Files frequently wait here because risk approval and documentation readiness are not synchronised.
Documentation to borrower. Offer issued and accepted. This segment is customer-visible and the most scrutinised. Its latency is almost always a downstream symptom of what accumulated earlier in the spine.
Mapping each segment and measuring each transition wait identifies the constraint. That is where E-S-S-A-M analysis begins.
E-S-S-A-M applied to the credit workflow
The E-S-S-A-M framework applies four phases in sequence. Each phase operates differently across the credit approval context.
Eliminate
The Eliminate phase removes non-value steps. In credit workflows, these typically include:
- Duplicate data entry where application fields are re-entered into credit-risk templates already present in the origination system.
- Confirmation emails between teams that function as informal workflow triggers. These exist because no formal routing mechanism was ever built.
- Pre-approval committee reviews for credits within a single approver's existing delegated authority.
None of these steps were designed deliberately. They evolved to fill gaps left by an unmapped process. Eliminate does not assign blame. It identifies what the workflow can run without.
Simplify and standardise
The Simplify & Standardise phase reduces variance across the remaining steps. In credit workflows, the highest-variance points are typically the credit memo format — inconsistent across business units — and the conditions register, where approvers add conditions without a shared structure, creating downstream ambiguity for documentation teams.
Standardising the credit memo to a fixed template reduces analyst preparation time. Standardising the conditions register to a structured checklist reduces documentation rework. Neither change requires a system modification. Both are process conventions enforced through the updated SOP.
Automate
The Automate phase applies automation to steps that are already standardised and repeatable. The highest-value automation targets in a credit workflow are:
- File completeness checks at the business-to-credit boundary. Incomplete files are returned before entering the credit queue, not after the analyst has already opened them.
- Routing notifications when a credit assessment reaches the risk review threshold.
- Status updates to relationship managers. Automated notifications eliminate the manual chasing calls that consume approver attention.
The automation layer should only touch steps that Simplify & Standardise has already made consistent. Automating a variable step produces automated inconsistency.
Migrate
Migrate is the most consequential phase for credit approval workflows. It is also the phase that teams most often skip.
Migrate reassigns work from high-cost, high-judgment resources to the appropriate tier. In a credit workflow, that means moving files within a delegated authority threshold out of the senior-approver queue at the routing layer — not by changing credit policy, but by encoding the policy that already exists.
Consider a hypothetical review at a mid-size bank in Malaysia. A senior credit manager with delegated authority up to RM 5 million spent roughly 40% of daily review time on files in the sub-RM 500,000 band. Those files qualified for analyst-level sign-off under the bank's own credit policy. They reached the senior queue by default because no routing rule had ever distinguished between authority bands. The policy was correct. The process had never used it.
Migrate resolves this by encoding the authority matrix into the routing logic. No policy amendment required. The senior manager's queue contracts. Decision turnaround on files that genuinely require senior judgment accelerates, because the queue is no longer diluted with sub-threshold work.
Senior-approver capacity is the scarcest asset in a lending bank. Most routing processes consume it indiscriminately. Migrate protects it by design.
The Migrate phase also has a second effect that teams rarely anticipate. When sub-threshold files exit the senior queue, the junior-approver tier's utilisation rises and its skills develop faster. Approver development accelerates because junior staff handle a genuine volume of decisions. The org builds depth rather than dependence on a narrow band of senior reviewers. That outcome has compounding value beyond the immediate cycle-time reduction.
What the Kuwait case demonstrates
A Kuwait bank reduced a 139-day procurement process to 57 days—a 59% cycle-time reduction, retiring 82 days of waste—using the ESSAM methodology. That case involved procurement, not credit approvals. The structural parallel is direct.
Both processes share the same pattern: sequential handoffs, approval dependencies, extended idle time between steps, and a cycle-time gap far wider than the sum of active processing times. Mapping the procurement workflow revealed that the bulk of the 139 days were wait time distributed across handoffs. Eliminating non-value steps, standardising documentation requirements, and deploying a revised SOP via WhatsApp drove the 82-day reduction.
Credit approval workflows in Singapore and Malaysia carry the same structural profile. The E-S-S-A-M method is the same. The entry point is mapping the handoffs and measuring the waits.
The ESSAM 7-step cycle applied to credit workflow improvement
ESSAM's 7-step improvement cycle — Baseline, Analyse, Optimise, Document, Deploy, Feedback, Repeat — maps directly to the credit workflow context.
Baseline. Conversational capture of the current approval path. No flowchart software, no specialist, no IT team required. A single session maps the full workflow from application receipt to offer dispatch.
Analyse. Identify each handoff point. Measure wait times at each boundary. Calculate the process efficiency ratio. Locate the constraint.
Optimise. Apply E-S-S-A-M in sequence. Eliminate the duplicate steps. Standardise the credit memo and conditions register. Automate completeness checks and routing notifications. Migrate sub-threshold files to the correct authority tier.
Document. Produce an updated SOP with the approved workflow, authority thresholds, and routing rules. This SOP becomes the single source of truth for the approvals team.
Deploy. Distribute the SOP via WhatsApp. WhatsApp penetration reaches 88% in Singapore and 92% in Malaysia (industry data, labeled). The approvals team receives the updated process on a channel they already use, without installing a new application or attending a training session.
Feedback. Collect exception logs and variation reports from the approvals team as the updated process runs.
Repeat. Use feedback to refine routing rules and authority thresholds in the next monthly cycle.
Each iteration builds on the last. Improvements compound across the quarterly cadence.
Before and after: what the audit trail records
The ESSAM baseline process produces a before/after audit view for each optimised workflow. For a credit approval workflow, the before-state records:
- Number of handoff steps across the decision spine.
- Wait time at each boundary transition.
- Rework loop frequency: how often files travel back upstream for supplementary information.
- Senior-approver queue composition by authority band.
The after-state records the same metrics following SOP deployment. The delta is the measured difference between two captured process states — not an estimate. This audit trail serves two purposes: it confirms the optimisation produced the intended result, and it provides the documentation that MAS and BNM-regulated banks in Singapore and Malaysia need to demonstrate that process changes are governed and traceable. A time-stamped baseline and a versioned SOP, produced in the same session, satisfy that audit expectation without generating a separate governance project. The compliance record is a by-product of the improvement process — not an additional task it creates.
For most credit-operations teams, the before/after view is the first time they have seen cycle time broken down at the handoff level. That visibility changes the improvement conversation. Teams stop debating whether the process is slow and start debating which boundary to fix next. The audit trail becomes the standing agenda for the monthly improvement cycle.
Where this approach has limits
The Migrate phase requires a defined authority matrix. If delegation thresholds are absent or inconsistently applied across the lending portfolio, Migrate cannot encode routing rules — there are no agreed rules to encode.
ESSAM accelerates expert work. It does not replace the judgment that credit decisions require. Files involving complex covenant structures, cross-default provisions, or multi-entity borrower relationships warrant senior review. Migrate moves routine, sub-threshold files away from senior queues. It does not touch judgment-intensive cases.
Where authority matrices are undefined, Simplify & Standardise provides the first-cycle value. Define the delegation thresholds as part of the SOP design process. Migrate follows in the next iteration, once thresholds are documented and agreed.
Map your approval spine before the next quarter starts
Describe your credit approval workflow to ESSAM — how many handoffs, where files stall, which queues run longest. ESSAM returns a baseline efficiency analysis, a waste map showing your highest-impact boundary, and a redesigned SOP ready for WhatsApp deployment to your approvals team.
One process description. One working session. Send it through at apac.essam.ai/contact and receive your baseline map before the next approval cycle begins.
Frequently asked questions
What is a credit approval workflow?
A credit approval workflow is the sequence of steps a bank follows from receiving a loan application to issuing a credit decision and offer letter. It spans four boundary transitions: business development to credit analysis, credit to risk review, risk to documentation, and documentation to the borrower.
Why do credit approvals take longer than the actual decision time?
Approval latency accumulates at handoff boundaries, not during analysis. A credit analyst may reach a decision in under 30 minutes, but a file waits hours or days to enter the queue, move between teams, and clear approval conditions. Measuring wait times at each boundary reveals where elapsed time can be reduced.
What does the Migrate phase of E-S-S-A-M do in a credit workflow?
Migrate reassigns work from high-cost, high-judgment resources to the appropriate tier. In credit terms, it routes files within a delegated authority band to the analyst or junior-approver level, rather than defaulting every file to the senior queue. Senior approvers only see decisions that require their specific judgment.
How long does it take to map and redesign a credit approval workflow using ESSAM?
The baseline capture takes a single conversational session. The E-S-S-A-M optimisation analysis follows in the same engagement. A redesigned SOP can be ready for WhatsApp deployment within days — not weeks of workshops or system integration work.
Can credit workflow improvements be deployed without changing core banking systems?
Yes. The E-S-S-A-M method targets the process, not the platform. Routing rules, authority thresholds, SOP conventions, and notification triggers can all be redesigned and distributed as updated SOPs via WhatsApp, without a system change, application installation, or formal retraining programme.
Related reading: