Process Mining Before Modernisation

Most loan modernisation programmes start from the process as it is documented: procedure manuals, BPMN diagrams from workshops and a target operating model. The trouble is that the documented process is rarely the one that actually runs. Over the years, real loan journeys collect rework loops, manual workarounds, approvals by email and exception paths that have become the norm. When a bank re-platforms on the basis of the documented process, one of two things tends to happen. Either the new system drops workarounds that people depend on, and operations struggle after go-live, or it faithfully digitises inefficiencies nobody knew were there. 

Process mining addresses this before a single requirement is written. It reconstructs the real process from the event data the bank's systems already record. This article explains why business analysts should start every lending modernisation with it, how the work is done and the gaps it typically reveals. 

What process mining is 

Every system involved in a loan application leaves a trail: the application is created, a document is uploaded, a credit check runs, an underwriter opens the case, an offer is generated, a contract is signed, the money is paid out. Each of these records has three essential pieces of information: 

A case identifier, usually the loan application number. 

An activity, such as "Income document received" or "Manual review started". 

A timestamp. 

Put those records together in time order for every application, and you have an event log. Process mining tools, from commercial platforms such as Celonis to open-source libraries such as PM4Py, read that log and reconstruct the process automatically. They show which paths applications really take, how often each path occurs, where time is spent and where cases go back and forth. 

Three uses matter most before a modernisation: 

Discovery: drawing the real process from the data, without assumptions. 

Conformance checking: comparing the real process with the documented one and listing every deviation. 

Performance analysis: measuring lead times, waiting times and rework, step by step. 

Where the data comes from in a loan journey 

A retail or SME loan journey typically crosses several systems, and the event log has to bring them together: 

• The digital channel or CRM, where the application starts. 
• The loan origination system, which manages the application workflow. 
• KYC and AML screening tools. 
• The credit decisioning engine, for scoring and automated decisions. 
• Document management, where payslips, statements and contracts are stored. 
• The core banking system, where the loan account is opened and funds are disbursed. 

The hard part is not the tooling. It is agreeing what counts as an activity and making sure the same application can be followed across systems that use different identifiers. This is where the business analyst's work starts. 

How a BA runs the analysis 

1. Start with a business question 

"Map the loan process" is too broad. A good starting question is specific: why does a standard consumer loan take eight days when the target is two? or what share of applications really goes to manual underwriting? The question decides the scope: which products, which channels and which time period. Twelve months of data usually captures seasonal effects and enough volume. 

2. Build an event dictionary 

Systems record technical events, while the business thinks in activities. The BA builds a dictionary that maps one to the other, for example: status code 140 in the origination system means "Sent to underwriting", and a document upload with type PAY means "Income proof received". This dictionary is often the most valuable artefact of the exercise, because it is the first time the bank has a shared definition of its own process steps. 

3. Extract and protect the data 

The data team extracts the events, and the BA validates them. Loan data is personal data, so customer identifiers are pseudonymised before analysis, and the data protection officer is involved from the start. Process mining needs case numbers, activities and timestamps, not customer names. 

4. Validate with the people who do the work 

Before drawing conclusions, the first results are reviewed with underwriters, back-office staff and branch advisers. They explain what the data can't: why a status is set twice, why a step seems to take zero seconds, or why some cases disappear for days. This step catches data-quality problems early and builds trust in the findings. 

5. Discover, compare and measure 

Only then does the analysis begin: the real process map, the deviations from the documented process and the time spent at each step. 

The gaps it usually reveals 

Every bank is different, but in loan journeys the same kinds of gaps appear again and again. 

Many more paths than anyone expected. The documented process shows one main path with a few exceptions. The event log often shows hundreds of variants. Usually a handful of variants covers most applications, and a long tail of rare paths takes a disproportionate share of effort. Knowing which is which tells the modernisation team what to design for and what to simplify. 

Manual review is the norm, not the exception. Procedures often describe manual underwriting as an exception for complex cases. The data regularly shows a much larger share of applications being reviewed by hand, often because automated rules are set conservatively or because data needed for an automated decision arrives late. 

Document loops. Customers are asked for the same document more than once: a payslip that was unreadable, a bank statement for the wrong period, a document requested by a second department that didn't see the first upload. Each loop adds days and frustrates the customer. 

Waiting time dominates. Actual work on an application often takes minutes or hours, while the application waits for days between steps: in a queue, waiting for a hand-off between teams or waiting for a customer reply. Modernisation that speeds up the work but leaves the hand-offs untouched barely changes the lead time. 

Steps that happen outside the systems. Gaps in the timeline, followed by a sudden status change, usually point to work done by email, spreadsheet or phone. These off-system steps are exactly what a new platform needs to capture, and they are invisible in workshop-based process maps. 

Steps in the wrong order. Conformance checking sometimes finds cases where a step happened before a check that should have preceded it, for example a contract generated before a final verification was recorded. Even when there is a valid explanation, such as a check done but recorded late, these cases matter for control frameworks. The EBA Guidelines on loan origination and monitoring (EBA/GL/2020/06) expect banks to have sound, documented credit-granting processes, and process mining gives evidence of how consistently those processes are followed. 

How the findings shape the modernisation 

Process mining doesn't replace requirements work; it gives it a factual starting point. For each significant deviation, the BA leads a decision with the business owner: 

• Eliminate it, because it is waste (repeated document requests, unnecessary hand-offs). 
• Automate it, because it is valuable but manual (common manual reviews that a well-designed rule could handle). 
• Formalise it, because it is a legitimate exception the new platform must support explicitly, instead of leaving it to email. 

The analysis also produces two things a modernisation programme usually lacks. 

A measured baseline. Lead time, waiting time, share of manual reviews, rework rate and first-time-right rate, all measured before the change. After go-live, the same measurements show whether the new platform delivered what the business case promised. 

A realistic migration picture. The real variants include applications that are in flight on the day of migration. Knowing which paths they can be in, and how many there typically are, makes the cut-over plan much more reliable. 

The limits to keep in mind 

Process mining is powerful, but it only sees what systems record. Work done entirely outside the systems leaves no trace beyond a gap. Batch jobs can give many events the same timestamp, and statuses set retrospectively can make the process look different from how it ran. That is why the validation step with the people who do the work is not optional, and why process mining works best alongside interviews and observation, not instead of them. 

It is also an analysis of the past. It shows how the process runs today, not how it should run tomorrow. The design of the future process remains a business decision, now made with facts on the table. 

Closing thought 

Modernising a loan journey is expensive, and the cost of building the wrong process is paid for years. Mapping the real process from event data before re-platforming takes weeks, not months, and it replaces assumptions with evidence: how many paths really exist, where time really goes and which workarounds the business can't do without. For a business analyst, it is the most reliable way to make sure the new platform is designed for the bank as it actually works, and for the bank it wants to become.