Payments Academy

LAB-02: Redesign the Payment Exception Repair Process

Process modelling

When a payment cannot be processed straight through, it lands in an exception queue where operations staff must repair it, return it or reject it. In many banks that queue is slow, opaque and full of rework, because nobody has mapped the process end to end. In this lab you model the as-is exception repair process, measure where time is lost, and design a to-be process that clears most exceptions on first touch. You will draw a BPMN diagram with clear swimlanes, add sequence diagrams for the system interactions, and model the exception flows for the most common failure types. You will also define the controls, the handoffs and the service levels for each step. By the end of the lab you will have a process design that operations can run, technology can build, and management can measure.

0 of 5 steps done. Tick each step as you finish it, your progress is saved in this browser.

  1. Spend time with the repair team and watch them work exceptions. Record every step, every system, every handoff and every wait. Note the five most common exception reasons, such as missing beneficiary account, invalid currency, sanction screening alert and amount mismatch. Measure the average age of an exception, the number of touches per case and the share that are resolved on first contact. Draw the as-is BPMN diagram with swimlanes for customer, operations, compliance and technology, and get the team to confirm the map is accurate before you change anything.

  2. Analyse the as-is map for the wastes: waiting for a customer reply, re-keying data between systems, duplicate screening checks, and cases that bounce between teams because ownership is unclear. For each waste, ask why it happens five times until you reach a root cause you can fix, such as no repair template or no IBAN check. Quantify the cost of each root cause in hours per week and in aged exceptions, so the redesign is argued with numbers, and agree the top three causes with the operations manager.

  3. Draw the to-be BPMN diagram with the same swimlanes. Build in auto repair for the simplest cases, such as a missing charge code from a default table, and a single repair screen showing the payment, the error and the suggested fix. Add clear decision points: repair, return to sender, escalate to compliance, or reject. Define a service level for each path, for example four hours for a data repair and one business day for a compliance escalation, and agree the service levels with the teams who must meet them.

  4. For the three most important flows, draw sequence diagrams that show the messages between the payment hub, the screening system, the core banking system and the repair workstation. Show the order of calls, the data passed at each step, and the response or timeout for each call. Include the status update to the customer at each major step, so the customer is never left guessing. Walk the diagrams through with a developer and a tester, and correct any step where the diagram assumes a system can do something it cannot.

  5. Write a separate exception flow for each of the five most common failure types, stating the trigger, the owner, the steps, the time limit and the escalation path. Add controls: a four-eyes check for any repair above 50,000 dollars, a full audit trail of every change, and a daily ageing report. Define the measures that will prove the redesign worked, such as straight through processing rate, first touch resolution, average exception age and rework rate. Present the to-be design to operations and compliance for sign off.

Templates.

Worked example. Harborline Bank, a fictional bank in Singapore, takes an average of 26 hours to clear a payment exception, and 40 percent of cases need three or more touches. The analyst maps the as-is process and finds that repair staff re-key beneficiary data from the payment hub into the core banking screen, wait for a customer reply by email, and re-screen every repaired payment manually. The redesign introduces a single repair screen that shows the pacs.008 message, the validation error and the suggested correction together, plus an auto repair rule that fills a missing charge bearer code from the customer profile. A payment of 18,000 Singapore dollars to a supplier in Hong Kong arrives with an incomplete beneficiary address. The system flags it, the repair screen suggests the address from the standing instruction, the operator confirms it in one click, and the payment is released within 40 minutes. The pilot shows first touch resolution rising from 45 percent to 78 percent, average exception age falling from 26 hours to 6 hours, and rework falling by half. Operations signs off the to-be design and asks for the same approach on the returns process next.

Deliverables.