For two years our commercial lending workflow was modeled as a 47-step BPMN diagram. It was a beautiful diagram. Every stakeholder had signed off on it. Auditors loved it. Our relationship bankers ignored it. Our average time-to-decision was 11 business days. When we rebuilt the same workflow as a case rather than a diagram, our time-to-decision dropped to 2.9 business days in a quarter.
This is the story of that rebuild. Including the parts where we were wrong.
When we first modeled commercial lending in 2023, we did what most banks do. We mapped every approved path through the process. Intake to KYC to financials to covenants to credit committee to term sheet to legal to signature to funding. Every fork, every conditional review, every special case was a branch on the diagram.
The result was thorough and accurate and almost completely useless to the people doing the work. Relationship bankers did not look at the diagram to understand where a deal was. They checked Slack, they checked email, and they checked three different spreadsheets. The diagram was a perfect model of the happy path and a terrible guide to real life, because real deals are almost never on the happy path.
Every interesting credit deal has at least three exceptions. Most have six or seven. Modeling them as branches on a diagram means you are drawing a new branch every time a deal breathes.
Consider a mid-market SME asking for a working capital line. In theory: intake, credit check, approval, funding. In practice: the client's financials are three months out of date, the KYC on the parent entity expired last week, one of the directors appears on a secondary sanctions list that turns out to be a different person with the same name, the facility requires a covenant modification that the credit committee wants to review twice, and the client changes the request from revolving to term during the legal phase.
On our 47-step diagram, each of those would be a decision point that routes the process down a specific branch. In practice, they happen in parallel, they happen out of order, and they sometimes un-happen when new information arrives. A diagram that models all of that becomes 147 steps, then 247, then nobody maintains it.
The rebuild reframed commercial lending as a case with four stages and a bunch of adaptive tasks that can run in parallel, out of order, and sometimes more than once.
The stages are the structure. Intake. Credit analysis. Approval. Closing. Every deal moves through those four stages in order. A deal cannot close before it is approved. It cannot be approved before it is analyzed. These constraints are real and we model them as such.
Within a stage, tasks are adaptive. KYC refresh is a task. Covenant modeling is a task. Sanctions rescreening is a task. Legal review is a task. Tasks can be created, reassigned, reopened, or closed by the people working the deal. The process does not care that sanctions got rescreened twice. It cares that the case has a record of both screens.
The first thing that changed was the relationship banker's day. Before the rebuild, the banker was spending most of their time chasing status across three tools. After the rebuild, the case is the tool. The banker opens the case, sees every open task, every pending decision, every document in one place, and acts on it.
The second thing that changed was what happened at the stage boundary. On the diagram, the boundary was a decision gate. On the case, it is a checklist of closure criteria. The banker cannot move a case out of credit analysis until the closure criteria are met, but those criteria can be satisfied in any order. The banker does not need to follow our imagined sequence.
The third thing that changed was exception handling. On the diagram, an exception meant a new branch. On the case, an exception is a new task on the existing case. The case itself does not have to be reshaped to accommodate the oddball deal. It just has more tasks on it.
Time-to-decision is the headline but it is not the most interesting number. The most interesting number is zero. Before the rebuild, we had an average of four "exception tickets" per week, where a deal had hit a case our diagram did not model and the work had to route around the tool. Since the rebuild, we have had zero. The tool accommodates whatever the deal needs.
The single best pushback we got from the risk and compliance teams was "how do we audit this?" This was a fair question. Auditors are used to tracing a path through a diagram. A case does not have a path. It has stages and tasks.
What we did, after some back and forth with our internal audit team, was treat every task closure as an immutable event. The case is effectively an event log. An auditor asking "how was this decision made" can replay the events in order, see who did what and when, and reconstruct the decision. They cannot trace a line through a diagram because there is no line. But they can reconstruct the decision in a way they could not on the old 47-step model, because the old model aggregated three conversations in Slack and an email thread into "analyst reviewed" and moved on.
A diagram that lies cleanly is not more auditable than a case that represents reality. We kept telling ourselves it was. It never was.
I want to be clear that I am not writing off BPMN. BPMN is great for workflows that are actually linear or nearly-linear. KYC refresh is a diagram. Customer onboarding is a diagram. Reconciliation is a diagram. Credit is not.
My test, which I use as a rule of thumb now, is this. If I can describe the workflow in two or three sentences and the sentences do not have too many "unless" or "except when" clauses, it is a diagram. If every sentence has an "unless" in it, it is a case. Commercial lending was always going to be a case. We just took three years to admit it.
We are extending the case model to M&A advisory and to internal investigations. Both have the same property: structure at the edges, chaos at the core. We think the same pattern will work. We will post again when we have numbers.
For the full story with architecture and rollout details, see the case study page. And if you are interested in how we chose between BPMN, flows, and cases, my colleague Rohan has a post about that.