Full article
A direct payment promise usually looks straightforward until one case needs a payee check, another is waiting on approval, and consumer care has no reliable status to share. At that point the issue is not the payment rail. It is control drift between teams, rules and systems.
This delivery assurance note sets out what a direct payment control layer needs to keep direct payment provision orderly without adding avoidable friction for claimants or internal teams. The discipline is simple enough: each step needs an owner, a date or time limit, and acceptance criteria. If your plan has no named owners and dates, it is not a plan, fix it.
Context
The visible problem is usually a delayed or disputed payment. The underlying problem is that payee verification, approval control and payment confirmation have been split across separate queues, inboxes or tools. Once that happens, status updates become guesswork and exceptions pile up in the gaps.
I was wrong about this on an earlier rollout. I assumed payment release would be the blocker. In a Q4 2025 review, the payment itself was completing in under two hours, while approval and evidence handling averaged nine working days. That is not a banking issue. It is a workflow design issue.
That matters because uncertainty is not neutral. The Office for National Statistics quarterly personal well-being data tracks measures such as anxiety and life satisfaction across the UK. You do not need to force a dramatic conclusion from that dataset to make the operational point: when people are waiting for money and cannot get a clear update, the interaction gets harder to recover. A believable date and a consistent explanation do more work than polished copy.
By the end of scoping, one page should show four basics: who owns triage, who owns payee verification, who approves release, and who confirms the outcome to the claimant. If that cannot be shown with sign-off dates, the control model is still too loose.
What is changing
A proper control layer for Payment Services does not treat verification, approval and status as separate admin tasks. It holds them together in one governed flow. That means the same case record should show the current owner, the latest decision, the evidence state, the payment state and the next update due.
For most standard cases, the path to green is not complicated, just defined. A workable operating model looks like this:
| Time window | Action | Owner | Acceptance criteria |
|---|---|---|---|
| 0-4 hours | Log the case, categorise it and send acknowledgement | Consumer care team | Case reference created, category assigned, next update date sent |
| 4-12 hours | Complete payee verification and evidence checks | Consumer care team with claimant input where needed | Mandatory fields complete, duplicate checks passed, payee details validated to agreed standard |
| 12-24 hours | Route for approval by value, policy and risk | Workflow owner and named approver | Correct threshold applied, decision logged, audit note attached |
| 24-40 hours | Release payment and capture status | Finance operations | Payment instruction accepted, status returned to case record, exception handling triggered if needed |
| 40-48 hours | Confirm outcome to claimant | Consumer care team | Confirmation includes amount, payment date or expected timing, and support route for follow-up |
The point is alignment. If payee verification passes but approval is still waiting in someone’s inbox, consumer care needs to see that. If finance has released the payment but status has not returned to the case, that gap needs flagging before the claimant asks. Otherwise teams start making reasonable-sounding assumptions, and that is where rework starts.
Yesterday, after stand up, PAY-102 was blocked by a missing invoice reference in approval. A quick call with the finance lead cleared it. New date set. Useful because the owner and dependency were obvious within minutes. Without that, the case would have sat in a shared inbox and everyone would have been a bit tight on time by lunch.
Operational checkpoint: in the first 30 live cases, track median time to verification, median time to approval and first-time payment success rate. If those three numbers are not visible weekly, the process is running on instinct.
Implications for control and claimant experience
When the control layer is weak, teams compensate manually. Consumer care chases finance for status. Finance asks whether the payee was actually verified. Approvers request evidence that should have been present at the start. None of that is dramatic. It is just expensive and slow.
A stronger consumer care interface reduces that drift by making the decision chain visible. The claimant benefit is straightforward: fewer contradictory updates, fewer duplicate document requests and a clearer expectation of what happens next. The internal benefit is just as practical: cleaner audit evidence, fewer payment retries and less exception handling in business-as-usual queues.
There are four decision points to settle before build starts:
- Approval thresholds. Set value bands and named approvers before configuration. A workable pattern might be agents up to £25, team leads up to £100 and operations managers up to £500, with anything above that routed to a senior owner. The exact values vary; the test does not. In UAT, 100% of cases should route to the correct approver.
- Payee verification rules. Define what must be checked before release, and what triggers re-verification if details change mid-case. If bank details are amended after approval, the workflow should not quietly carry on as if nothing happened.
- Status update points. Pre-agree when the claimant gets an acknowledgement, an evidence request, an approval outcome and a payment confirmation. Each message should include what happens next and by when.
- Exception routing. High-value, suspected fraud or conflicting-evidence cases need a separate path with a senior owner and review date. If this route is vague, the standard queue gets clogged and routine cases suffer for it.
One useful UAT test between 14:00 and 16:00 is to rerun the trickiest case type with an awkward edge case, such as duplicate receipts or amended bank details after initial verification. Tests tend to pass once that edge case is covered. Before then, they only look passed.
Risks and mitigations
Most failure modes in a controlled payment workflow are predictable. Good. Predictable risks are easier to monitor and easier to fix.
| Failure mode | Observable signal | Risk | Mitigation |
|---|---|---|---|
| Approval black hole | Cases idle for more than 8 business hours with no decision | SLA breaches and inconsistent outcomes | Auto-chaser at 4 hours, escalation to deputy at 8 hours, named leave cover |
| Payee mismatch or incorrect details | Payment failure, manual rework or returned funds | Delay, duplicate handling, claimant confusion | Validate details at entry, require confirmation before release, monitor first-time success rate weekly |
| Status drift between systems | Finance shows released while consumer care still shows pending | Contradictory updates and avoidable contact volume | Write payment status back to the case record, with reconciliation checks and exception alerts |
| Ambiguous evidence rules | Repeated document requests and long pauses before approval | Cycle time consumed before a decision is made | Case-type evidence checklist with examples of acceptable proof and minimum required data |
| Complex cases mixed into the standard queue | Routine cases slowed by a small number of high-effort exceptions | Missed targets across the board | Separate queue, explicit entry criteria, senior owner and weekly review cadence |
There is a practical point here. Not every case belongs on the same SLA. Sensitive or high-risk cases often need a different route, and pretending otherwise does not help the claimant or the audit trail. Publish the separate path, name the owner and say what the review standard is. People can work with a slower process if it is clear and fair.
Operational checkpoint: review breach reasons weekly for the first month. If more than 20% of breaches come from one source, such as missing evidence or delayed approval, fix that design fault before asking teams to move faster. Speed is usually a design problem wearing a people problem costume.
Actions to consider
If you want Payment Services to support direct payment provision cleanly, keep the implementation sequence tight and evidence-led. No magic here. Just decisions made in the right order.
| Phase | Owner | Date target | Output | Success measure |
|---|---|---|---|---|
| Scoping and policy decisions | Operations lead | End of week 1 | Signed process map, approval thresholds, payee verification rules, exception criteria | Single agreed workflow version signed off by operations, finance and compliance |
| Configuration | Implementation owner, with Holograph where delivery support is required | End of week 3 | Routing logic, evidence fields, templates, reconciliation and escalation rules | 100% of agreed UAT scenarios route and update status as designed |
| Testing and training | Consumer care manager and finance operations lead | End of week 4 | Five to ten end-to-end test cases, runbook, deputy cover and team training | Critical defects closed, status updates visible, hand-offs rehearsed |
| Go-live review | Operations lead | Day 30 post-launch | Breach report, payment success report, reconciliation review and change log | Median resolution time, first-time payment success and top breach causes visible and owned |
Two assumptions should be flagged early. One, the approver hierarchy can be agreed inside week 1. Two, finance can return payment status to the case record without manual intervention. If either assumption fails, dates move. Better to say that on day 2 than pretend everything is fine until day 20.
And one admission, because these plans rarely behave like neat diagrams. I have underestimated effort before when the data feed between case management and payment release was trickier than expected. The updated plan held once we added buffer for mapping, retry logic and status reconciliation. Slightly annoying at the time. Better than finding out after launch.
What good looks like
A sound control layer gives each team what it actually needs. Consumer care gets a usable current status. Finance gets verified payee details and a clean release instruction. Approvers get the right evidence at the right threshold. Compliance gets an audit trail that shows who decided what, when and on what basis.
That is the real job of Payment Services. Not to make a workflow look sophisticated, but to keep approval, payee verification and payment confirmation aligned well enough that the process stays fair under pressure. Calm systems beat clever-looking ones, every time.
If you are reviewing your current process, get operations, finance and consumer care in a room and walk one live direct payment journey through Payment Services from start to finish. Name the owners, set the dates and mark the points where approval, payee verification or status updates drift apart. If you want a practical next step, the Payment Services team can help you run that mapping session, agree the first acceptance criteria and set out a sensible path to green.
