Give the people inside the bank one place to review, screen, question, and decide on an application — so that the twenty-four-hours-to-three-days promise made on the customer's side is something the bank can actually keep.

Context

This is the journey most portfolios never show, because nobody outside the bank ever sees it.

Under the paper model, an application arrived as a folder. Governance read it, checked it, and typed it into Flex by hand. Name screening happened in a separate system that produced a PDF report. Mandates were built in another system again. Anything unclear — a blurred document, a missing page, a question about a partner — left the process entirely and became a phone call or an email to the Relationship Manager.

So the work was distributed across three systems and an unrecorded conversation. Every handoff was a place where time was lost and nothing was written down.

The unit doing this work is the Account Opening Unit, and inside it two roles matter: governance reviews the application, its documents, its mandates, and takes the decision; compliance works the name-screening results. Maker and checker are different people — the person who assesses is not the person who approves. That separation is the reason the rest of the design can be as fast as it is.

Application queue listing submitted applications with status, risk level and turnaround time — The queue an officer opens each morning — the folder on a desk, replaced by a list that knows how long it has been waiting.

Name screening summary report grouped by conclusion for every individual and company on the application — Name screening, brought inside. This used to arrive as a PDF from a separate system — readable, but nothing could be done to it.

Mandate rules list showing signing authority rules for the account — Mandates, the second system folded in — built here rather than in a third place the officer had to open.

Modal for raising an exception, with a classified reason and the specific document it points at — Raising an exception — the classification is not reporting metadata. It is the address the replacement will land at.

Exception trail listing every query raised on an application with reason, stage, status, author and timestamp — The trail — not a log of failures, but a record of the conversation the bank used to have by phone and never wrote down.

Decision

Fold the separate systems in, and give the exception a life

Two systems came inside. Name screening and mandates both moved into the workflow rather than staying alongside it. The point is not consolidation for its own sake — it is that the officer never leaves. Assessment, evidence, and decision now sit in one place, and the round trips that were consuming the turnaround time disappear. Where the bank's other systems are still needed — deeper fraud investigation, verifying a compliance concern — those stay outside, deliberately. They are not part of the application's normal path, and pretending otherwise would have made the workflow pretend to be something it isn't. The exception became an object. This is the part I care most about. In the paper process, a query was an interruption. In this system, an exception is a structured record: a classified reason, the stage it was raised at, a status, who commented, when — and, critically, which specific artefact it points at. That precision is the whole point. A national ID for the second partner uploads with a clear front and an unreadable back. OCR reads the front; the customer confirms it. But the back is unusable. The exception is not "document rejected" — it is a targeted request for one side of one document belonging to one named partner. The replacement lands in place. The old file moves to the archive, and at fulfilment the officer sees only the current version. Without the classification, the system would not know what to replace with what. The category isn't reporting metadata — it's the address of the replacement. And this is what closes the loop across the three systems: exceptions and Need customer clarification both surface in the customer portal as a question the customer answers. The invisible phone call became a channel with a record. The five outcomes were already real. Approve, reject, need customer clarification, refer to compliance, refer to fraud — all five existed in the paper process. I did not invent them; I made them explicit as actions with structured reasons attached. Referral is worth naming precisely: the application doesn't move. It stays exactly where it is. What changes is that a specialist with different permissions opens it — the only person who can record that a subject is not a fraud risk after checking systems this workflow cannot see. The referral transfers responsibility, not the file.

The interface

Name screening. Results grouped by conclusion — exact match, no violation, discounted, potential, no conclusion — for every individual and company on the application. A row expands to the evidence behind it: the matched name, the service hit ID, the risk category, and the reason. Previously this arrived as a PDF: readable, but not actionable. Here the judgement happens in the same place as the evidence.

The exception trail. Every query ever raised on an application, with its reason, stage, status, author and timestamp. Not a log of failures — a record of the conversation the bank used to have by phone.

The audit log, and the application timeline beside it. The log records which unit held the application, when it was assigned, when it was picked up, when it was released, and how long it took — to the second. The timeline shows what actually changed, field by field, old value to new, alongside when the customer was asked something and when they answered.

The decision. Five outcomes, each opening a set of structured reasons plus free comment. Where exceptions are still unresolved, they are surfaced above the decision area — the officer sees what is outstanding before choosing, not after.

All interface work is shown as designed. Names, figures and identifiers are sample values; the production visual skin is under NDA.

What the first version got wrong

MVP-1 shipped, and then we watched it being used. This is the part I would want a hiring manager to read.

MVP-1. A vertical left-hand navigation listing every stage as a step, including exception trail and audit history.

The current version. Horizontal stage tabs, exceptions and audit log promoted to permanent access in the header, and the content given the full width of the screen.

Four things changed, each for a specific reason:

1 · The navigation was eating the screen. A vertical rail costs width permanently, and in a system that is almost entirely tables and reports, width is the resource. Fields were squeezed into a narrow column while the right side sat empty. Moving to horizontal tabs gave the content the whole viewport.

2 · The exception trail and audit log were stages; they became universal. They were steps you passed through. But an officer needs the history while reviewing, not as a destination. They moved from being places in a sequence to being a layer available anywhere.

3 · The sequence was designed for the maker and broke the checker. Modules had to be completed in order. That fits the person entering and assessing — it actively obstructs the person verifying, whose work is to move between sections and compare. Free navigation between modules replaced the forced sequence.

This is the second time this exact lesson found me. On the customer journey I designed modular navigation, conceded it to a technical constraint, and the real need later brought it back. Here the sequence was imposed and reality broke it. The same principle, learned from both directions: a linear path serves whoever is filling something in, and fails whoever is checking it.

4 · Editing was restricted to some fields; it is now open on all of them. A partial edit capability just relocates the problem — the officer hits the one field they cannot change and the whole flow stalls.

Exception mapping was also too coarse in MVP-1 to support the targeted replacement described above, and the accessibility work was rebuilt entirely in the current version.

How the problems were found

The turnaround time was too high. That was the signal — not a complaint.

So I investigated, sat with the officers, and watched them work. And this is the method rather than the anecdote: in an interview, the officer cannot tell you what the problem is. They have adapted to the system; the friction has become the job. What they can't articulate, their behaviour shows.

What the behaviour showed was an officer working through name-screening results one row at a time, on a report that routinely runs to dozens of entries. So I proposed selection and a bulk action.

A name screening row expanded to show the matched name, service hit ID, risk category and reason — What the watching found — one row, opened, judged, closed. Then the next. On a report that routinely runs to dozens.

Application list with filters applied, narrowing the queue — Filtering and selection — safe here only because the decision sits downstream, in a different pair of hands.

That change is only safe because of the maker–checker split. If the same person assessed and approved, acting on many results at once would concentrate risk. With the decision sitting downstream, in a different pair of hands, it removes repetition from a step that is not final.

On preventing errors

There is no gate stopping an officer from marking a result incorrectly. That is a deliberate position, not a gap.

You cannot add a reviewer for the reviewer for the reviewer. Past a point, layered checking stops being safety and becomes paralysis — and in a system whose entire purpose is compressing weeks into days, another mandatory approval would undo the thing it was built for.

The protection is different in kind: every action is attributed, timestamped and visible; and the person who decides is not the person who assessed. Errors are not made impossible — they are made attributable, and they are made visible to a second pair of eyes before anything is final. In regulated systems that is usually the more honest design.

Audit log recording which unit held the application, when it was assigned, picked up and released, timed to the second — The alternative to preventing the error — every action owned, timestamped, and readable by someone who was not in the room.

Result

The turnaround the customer experiences — twenty-four hours to three days from submission to an active account — is not a promise made on the customer's screen. It is a property of this system: nothing is re-keyed, nothing leaves the workflow, and every open question has a channel and a record.

And the workflow measures itself. Risk level, turnaround time and status sit on the dashboard; the audit log times every handoff to the second. The service level is observable rather than asserted — which is what makes it a service level at all.

Application list with a notification banner announcing newly arrived work — The service level, made observable — risk, turnaround and status on the surface, so nobody has to ask how long something has been sitting.

Next chapter: Customer Portal & Notifications — the same application, seen by the person waiting.