For banks, credit unions and lenders

The clock started on Tuesday. You found out on the following Monday.

A dispute, a complaint, a servicing request — each one starts a deadline you are accountable for, and most operations cannot see those clocks while they are running. They see them afterwards, in a reconstruction, usually because somebody is already asking a question you would rather have answered first.

What servicing actually looks like from inside

A cardholder disputes a transaction. That starts a regulated sequence with defined obligations and defined timing, and the timing does not care whether the case is sitting in a queue, waiting on a merchant, waiting on documentation, or waiting because the person handling it is on leave. The clock runs the same in all four cases and only one of them looks like a problem on a dashboard.

A complaint arrives — through a branch, a call, a portal, a regulator’s own channel — and how it is categorised in the first hour determines everything downstream. Categorise it as a service issue and it goes one way; categorise it as a potential compliance matter and it goes another. That decision is often made quickly, by whoever is available, and is rarely revisited.

Meanwhile the systems that hold these cases are excellent at recording what was done and largely silent about what has not been done yet. A case that nobody has touched for six days generates no event. Absence produces no record, and absence is exactly the thing you needed to know about.

When examination time arrives, the work is reconstruction: pulling the population, sampling it, tracing individual cases through several systems, and assembling a narrative that the procedure was followed. That exercise consumes senior people for weeks, and it is genuinely harder than the servicing itself.

And every automation proposal arrives into a governance conversation, correctly. Anything that touches a customer outcome has to be explainable, testable, monitored and owned — which is why so many good ideas in this industry stop at the model risk review rather than at the business case.

You are accountable for a clock your systems do not show you

Servicing systems record actions taken and do not record time elapsed without action — so the state that creates regulatory exposure, a case ageing untouched, is the one state that generates no signal.

This is why adding staff helps less than it should. Extra capacity is applied to the cases people can see, and the cases that create exposure are precisely the ones nobody is looking at. Volume is visible; ageing is not.

It is also why quality assurance by sampling feels unsatisfying to the people who run it. A sample tells you about the population with a confidence interval. An examiner does not review your sample — they review cases, including the ones your sample did not contain.

The correction is not a bigger sample or a faster team. It is to make elapsed time a first-class thing the operation can see: which cases are running against a clock, how much of that clock is gone, what each one is waiting for, and which ones will breach if nothing changes today. That reframes the work from reactive to scheduled, and it makes the examination narrative a by-product of doing the work rather than a project after it.

And it changes what evidence means. A record assembled during the work, action by action, with authority and timestamp, is a different artefact from a narrative assembled afterwards to explain the work. Only one of them is difficult to argue with.

What moves, and what an examiner would be able to see

Cases visible against their clock while it is running — measured by the count of open cases with time-remaining known, versus those whose deadline is only computable retrospectively.

Cases ageing untouched — measured by days since last action per open case, including the tail — the population, not a sample.

Deadline breaches, and how they happened — measured by breaches counted against your own baseline, each traced to the step where the wait occurred.

Consistency of complaint categorisation — measured by category assigned against the rule that produced it, reviewable across the whole population rather than a sample.

Time senior staff spend assembling examination narrative — measured by hours logged to preparation before and after, on comparable review cycles.

Coverage of quality review — measured by the share of cases carrying a machine-readable record of what was done, versus the share reviewed by sampling.

Distance between written procedure and observed practice — measured by cases whose actual path diverged from the documented one, surfaced continuously rather than at review.

any regulatory determination, any credit or lending decision, and any judgement about whether a specific case was correctly resolved. Nothing here decides a dispute, adjudicates a complaint, or makes a decision that affects a consumer’s access to credit. Those are yours, and a vendor claiming otherwise should worry you.

Working inside the core, the servicing platform and the case system

Read access to the systems already holding case state, through their documented interfaces. Nothing migrates, no parallel record of a customer is created, and your system of record remains the system of record — a second place where a dispute’s status lives is a governance problem waiting to be found.

Writing back is a separate decision made per step, and it is bounded by an authority grant your compliance function approved. Read and write are two different permissions on purpose, because collapsing them is how a visibility project becomes a change nobody signed off.

Third-party risk oversight is easier when the answers are documents rather than a call. The architecture, data flow, subprocessor list and access model exist in a form your vendor management team can put straight into their file.

Financial data, and what happens to it

Customer financial information is governed by obligations that attach through the contract and the data class, not through a badge on a website. Where those obligations apply to a deployment, they are marked applicability-gated, which is the accurate description and the one your third-party risk team is trained to read correctly.

Operational access is not permission to train. Customer financial data does not become material improving anything that serves another institution. In this industry that is not a preference, it is the sentence that has to be true before the rest of the conversation is worth having.

Every consequential action carries a receipt naming its authority and its time. That record is the evidence artefact — produced during the work rather than assembled afterwards to describe it — and it is yours to export without a request to us.

Where a decision affects a customer outcome, the authority for it is written down before it is exercised, scoped narrowly enough to enumerate, and revocable without a contract change. Your governance function should be able to read that grant and say yes or no to it on its own terms.

Third-party risk, model governance, and the examination question

Three reviews run here and they ask different questions. Third-party risk asks what the vendor can reach and what happens if it fails. Model governance asks what decides what, how it is tested and monitored, and who owns it. Compliance asks what an examiner will see.

The answer that makes all three shorter is the same: what is delegated is enumerated, what is decided is recorded with its authority, and nothing that affects a consumer outcome happens outside a grant your own governance function wrote. A capability that cannot be enumerated cannot be governed, and should not be bought.

We do not claim certifications we do not hold. An attestation that is in progress is described as in progress, and where an obligation attaches only under a specific contract or data class it is marked applicability-gated rather than presented as standing.

One case type, observed, with nothing delegated

A single case type carrying a regulatory clock — a dispute queue, a complaint category, or one servicing request type — observed read-only, with no authority to act on any case.

Observation changes nothing and decides nothing. What it produces is the ageing profile of that case type across the whole population rather than a sample: how many are running against a clock, how much of it is gone, what each is waiting for, and how the elapsed time divides between work and waiting.

That profile is worth having whatever happens next, and it is the thing most servicing operations cannot currently produce for their own book. It is also the honest input to the staffing conversation, which otherwise runs on volume — and volume was never the number that created exposure.

If you proceed, the first delegation is one narrow step, agreed with your compliance function, with the grant written down and a stopping condition set in advance. Nothing that determines a customer outcome is in that first step, and it should not be in the fifth either.

Questions buyers actually ask

Anything touching a customer outcome goes through model risk governance, and that takes months.

It should, and the observation phase is deliberately designed not to enter it: read-only, nothing decided, no customer outcome affected. That gets you the ageing profile while the governance conversation happens in parallel rather than in front of it. When a delegation is eventually proposed, it arrives as an enumerated grant with a defined escalation boundary — which is a reviewable object rather than a capability claim, and that is usually the difference between a governance review that concludes and one that stalls.

Our examiners will ask who is accountable for a decision this system made.

You are, and the record is built to show exactly that. Every action carries the authority under which it was taken, and that authority traces back to a grant a named person in your institution wrote and can withdraw. Nothing acts outside a grant. Where a case falls outside one, it escalates to a named person with the decision stated — it is not resolved on a best guess. If an examiner asks who decided, the record answers with a person, not a system.

We already have workflow and case management. This sounds like a duplicate.

Case management records what was done. The gap this addresses is the opposite state — a case where nothing has been done for six days, which generates no event precisely because nothing happened. If your current systems can already show you, right now, every open case ranked by time remaining on its clock and what each one is waiting for, then this would be a duplicate and you should not buy it.

Our data cannot leave our environment, and some of it cannot leave the country.

Data residency is applicability-gated: it applies where your contract and deployment create the obligation, and it is a scoping question answered before anything is connected rather than a capability claimed on a page. Bring the requirement to scoping with the specific boundary you need. If we cannot meet it for your deployment, that is a real answer and you should get it in week one rather than in procurement.

Every vendor tells us their AI is explainable. Ours has to be defensible to a regulator.

Those are different standards and you are right to separate them. The defensible version is not a narrative about how a model reasons — it is a record of what was done, under whose authority, at what time, and what the rule was. Where a rule decided something, the rule is readable and was approved by your people. Where judgement was required, it escalated to a person. That is a smaller claim than most vendors make and it is the one that survives being asked about.