Payment Investigations and Exception Management. Trace inquiries, repairs, recovery, claims, status handling and escalation across payment operations.
Block 14 · Chapter 68 of 75
Payment investigations begin when the normal straight-through story breaks.
A customer says a beneficiary has not received a wire. A payroll originator sees one missing employee credit. A PAD collector disputes a return. An Interac customer reports that money left the account but the recipient cannot see it. A high-value payment settled but the receiving bank says it cannot apply the funds. A reconciliation team finds settlement evidence with no matching customer posting. A real-time payment times out and nobody should assume whether it succeeded or failed.
These cases look different, but the investigation discipline is the same:
identify the original transaction, reconstruct its state from evidence, determine which institution or system owns the unresolved step, ask the smallest useful question, take the permitted corrective action, and close only when the financial and customer outcomes reconcile.
An investigation is not a substitute for payment state. It is a process for proving payment state.
This chapter focuses on Canadian payment operations across AFT/ACSS, PAD, Interac, Lynx, cross-border payments and the Real-Time Rail (RTR) modernization programme. As of 2026-10-05, RTR is not yet a production customer rail: Payments Canada states a Q4 2026 launch target, with approved rules and industry solution-assurance testing underway. It also explains how ISO 20022 data, UETR, pacs.004 returns, camt reporting, internal event histories and ledger evidence support investigation without turning the chapter into a message catalogue.
What you should be able to do after this chapter
After working through this chapter, you should be able to:
- define an investigation case separately from the original payment;
- identify the minimum evidence needed before contacting another bank;
- reconstruct a payment across customer, channel, hub, rail, settlement and ledger events;
- distinguish inquiry, repair, trace, recall, return, claim, dispute and fraud recovery;
- use external identifiers such as UETR or rail references without losing the bank’s internal payment identity;
- explain how AFT item-level exceptions differ from Lynx and cross-border investigations;
- investigate a missing beneficiary credit without assuming settlement failure;
- investigate duplicate and uncertain outcomes safely;
- distinguish message status from funds status;
- design operational queues, priorities and service levels around customer harm and financial exposure;
- preserve a complete audit trail of contacts, evidence and decisions;
- identify when an investigation becomes a fraud, sanctions, legal or reconciliation case;
- close cases only after financial postings and customer communication are complete;
- test investigation tooling against partial, late and contradictory evidence.
Chapter navigator
- What a payment investigation is
- Start with the original transaction
- Reconstruct the end-to-end state
- Investigation patterns by payment rail
- Interbank inquiries, traces, recalls and claims
- ISO 20022 and investigation data
- Uncertain outcomes, duplicates and technical failures
- Fraud, sanctions and legal escalation
- Case management, ownership and service levels
- Accounting, reconciliation and closure
- Practical investigation scenarios
- Implementation, testing and authoritative references
1. What a payment investigation is
A payment investigation is a controlled effort to answer a question that normal payment processing did not answer clearly enough.
Typical questions are:
- Was the payment received by the bank?
- Was it authorized?
- Was it released externally?
- Did the external system accept it?
- Did it settle?
- Did the receiving institution receive the payment?
- Did the receiving institution post it to the beneficiary?
- Was it returned?
- Was it duplicated?
- Can it still be cancelled or recalled?
- Was the customer debited correctly?
- Is the payment sitting in suspense?
- Was the wrong beneficiary paid?
- Is fraud suspected?
- Who owns the next action?
The investigation should be framed as a question, not as a conclusion.
Bad case title:
Payment failed
Better:
Beneficiary reports non-receipt; Lynx settlement evidence present; beneficiary posting not yet confirmed
The second title prevents the investigator from searching for the wrong failure.
Investigation is not repair
Repair happens before release when data can still be corrected.
Investigation usually begins after:
- uncertain state;
- unexpected response;
- customer inquiry;
- return;
- reconciliation break;
- downstream non-posting.
Investigation is not recall
A recall is one possible action from an investigation.
The investigator may discover that:
- payment never left the bank, so no recall is needed;
- payment was already returned;
- payment went to the correct bank but wrong account;
- duplicate is internal only;
- beneficiary bank needs more information;
- fraud recovery process is required.
Investigation is not customer reimbursement
The bank may decide to credit a customer before interbank recovery is complete under product, legal or customer-treatment policy.
That customer credit is a financial decision.
The investigation continues until the interbank and accounting position is also resolved.
2. Start with the original transaction
The single strongest investigation control is exact transaction identity.
A case should not begin with:
- customer name only;
- amount only;
- “payment last Tuesday”;
- screenshot only.
Those are search aids, not transaction identity.
Internal identity
Useful internal identifiers include:
- paymentId;
- instructionId;
- fileId and item sequence;
- customer reference;
- channel request ID;
- booking reference;
- case reference.
External identity
Depending on rail:
- Lynx message/payment reference;
- UETR where applicable;
- AFT trace/reference data;
- Interac reference;
- SWIFT references;
- clearing/settlement reference;
- return transaction identifier.
Why amount/date are weak
A corporate customer can send fifty CAD 10,000 payments on the same day.
Matching on amount and date can connect the wrong beneficiary to the wrong case.
The investigation platform should search by multiple fields but should bind the case to a unique original record before corrective action.
Payment family
A useful model is:
Business transaction
├─ customer instruction
├─ external payment
├─ settlement event
├─ customer posting
├─ return/recall events
└─ investigation cases
This lets the bank preserve multiple events without overwriting history.
3. Reconstruct the end-to-end state
A good investigator works left to right.
Stage 1: initiation
Confirm:
- customer/channel;
- date/time;
- amount/currency;
- beneficiary details;
- requested execution date;
- authorization method;
- approvals;
- customer reference.
Question:
What did the customer actually instruct?
Stage 2: bank acceptance
Confirm:
- validation result;
- account status;
- available funds;
- limits;
- duplicate controls;
- fraud result;
- sanctions/compliance result;
- enrichment;
- routing decision.
Question:
What did the bank agree to process?
Stage 3: external release
Confirm:
- message/file created;
- exact version;
- sending gateway acknowledgement;
- external reference;
- timestamp;
- route;
- participant.
Question:
Did the bank actually hand the transaction to the rail/network?
Stage 4: clearing or exchange
Confirm:
- accepted/rejected;
- clearing cycle/stream;
- participant position where relevant;
- response codes.
Question:
Did the external arrangement accept the transaction?
Stage 5: settlement
Confirm:
- settlement event;
- settlement account;
- amount/currency;
- finality status;
- date/time.
Question:
Did value move between the relevant institutions?
For Lynx, Payments Canada Rule 10 and system records matter because settlement finality changes the available corrective path.
For ACSS, the investigator may need to understand the batch position and item flow rather than look for an individual RTGS settlement event.
Stage 6: beneficiary posting
Confirm:
- receiving bank received sufficient data;
- beneficiary account identified;
- posting succeeded/failed;
- funds availability;
- suspense/repair at receiving bank.
Question:
Did the beneficiary actually receive usable funds?
Settlement to a financial institution and credit to the beneficiary are not identical events.
Stage 7: customer reporting
Confirm:
- sender statement;
- beneficiary statement where available through customer evidence;
- notifications;
- corporate status report;
- return notice.
Question:
What did each customer see, and did it match the underlying state?
Stage 8: corrective actions
Confirm:
- return;
- recall request;
- reversal;
- fee refund;
- customer provisional credit;
- fraud recovery.
Question:
What happened after the exception was identified?
4. Investigation patterns by payment rail
The same question requires different evidence on different rails.
AFT and ACSS
AFT investigations are often file-and-item investigations.
Typical issues:
- item rejected before exchange;
- wrong account data;
- closed account return;
- payroll item missing;
- duplicate file;
- wrong due date;
- file accepted but item returned;
- mismatch between originator report and bank report.
Evidence:
- customer file;
- file control totals;
- item sequence;
- AFT transaction type;
- processing date;
- return reason;
- clearing/exchange reports;
- originator account posting.
The investigator must avoid treating a file-level “accepted” response as proof that every item credited successfully.
PAD
PAD investigations require mandate evidence as well as payment evidence.
Questions:
- was a valid PAD agreement present?
- was debit amount/date consistent?
- was item returned?
- was it re-presented?
- did customer dispute authorization?
- was reimbursement posted?
- did collector receive settlement before return?
Payment and mandate cases may need to be linked but separately owned.
Interac e-Transfer
Common investigation questions:
- sender says transfer completed but recipient cannot find it;
- transfer notification not received;
- Autodeposit destination disputed;
- customer sent to wrong contact;
- scam suspected;
- transfer cancelled or expired.
The investigator should separate:
- notification;
- transfer/payment status;
- sender account debit;
- recipient deposit;
- fraud event.
Email/SMS is a notification channel, not settlement evidence.
Lynx domestic wire
Common patterns:
- beneficiary non-receipt;
- wrong account;
- duplicate wire;
- return request;
- compliance hold at receiving bank;
- payment received but unallocated.
Evidence should include:
- original customer instruction;
- pacs.008 or pacs.009 data as applicable;
- UETR/reference;
- Lynx acknowledgement/settlement evidence;
- return pacs.004 if returned;
- customer ledger.
Payments Canada publishes current Lynx ISO 20022 specifications for pacs.008, pacs.009 and pacs.004 and camt.053 reporting.
Cross-border wire
Cross-border investigations are more complex because message path and funds path may diverge.
Possible parties:
- ordering customer;
- Canadian sending bank;
- intermediary;
- correspondent;
- beneficiary bank;
- beneficiary.
Possible evidence:
- SWIFT gpi/UETR tracking where available;
- nostro debits/credits;
- correspondent messages;
- beneficiary-bank inquiry;
- FX records;
- charges;
- return.
Never conclude “beneficiary bank has funds” solely because a SWIFT message was delivered.
RTR (pre-launch status and post-launch design)
RTR investigations must be real-time aware.
As of 2026-10-05, RTR remains pre-production. Payments Canada describes it as launching in Q4 2026 and reports that its by-law and rules have been approved while industry solution-assurance testing is underway. The controls below are therefore implementation and test requirements for the planned service, not a description of current live customer processing.
A timeout must trigger:
- idempotent status lookup;
- settlement-state reconstruction;
- duplicate prevention;
- rapid customer update.
Investigation procedures should be built and tested before production. Do not present a target launch window, a participant’s test status or a simulated result as evidence of a live RTR customer transaction.
5. Interbank inquiries, traces, recalls and claims
The investigation team should choose the narrowest appropriate external interaction.
Inquiry
Use when information is missing.
Examples:
- confirm beneficiary posting;
- request reason for non-credit;
- clarify returned amount;
- request additional reference.
Trace
A trace reconstructs the route/status across systems or institutions.
For a domestic high-value payment, trace may be short.
For cross-border correspondent banking, it may involve multiple institutions.
Recall
Use when the sender wants value returned.
Reasons:
- customer error;
- duplicate;
- fraud;
- payment no longer due.
A recall request should include:
- exact original reference;
- reason;
- amount;
- contact point;
- urgency where applicable.
Recall remains a request until value returns.
Claim
A claim asserts a financial or rule-based entitlement.
Claims require stronger evidence than an ordinary inquiry.
The bank should distinguish:
- payment recovery;
- fee claim;
- compensation claim;
- fraud claim;
- customer complaint.
Contact discipline
Interbank messages should be:
- concise;
- factual;
- reference-complete;
- free of speculation;
- routed to correct contact.
Weak:
“Customer says missing. Please check.”
Better:
“Original Lynx payment reference X, CAD amount Y, settlement confirmed at time Z. Beneficiary reports non-receipt. Please confirm posting status or reason for non-credit.”
Avoid message storms
If a case is already open:
- do not send multiple duplicate inquiries from branch, operations and fraud;
- centralize communication;
- link all responses to one case.
Duplicate external requests waste time and can create conflicting instructions.
6. ISO 20022 and investigation data
ISO 20022 helps investigations when the bank preserves its business data.
It does not eliminate investigations.
UETR
A Unique End-to-end Transaction Reference supports transaction correlation in applicable payment contexts.
Use it as:
- cross-system key;
- search key;
- link to tracking evidence.
Do not assume UETR alone proves customer posting.
pacs.008
Carries FI-to-FI customer credit-transfer information.
Investigation-relevant data can include:
- parties;
- accounts;
- agents;
- amount;
- remittance;
- references.
pacs.009
Carries FI-to-FI credit-transfer information and is relevant in interbank contexts.
Do not treat pacs.009 as automatically meaning a customer payment.
pacs.004
Payment return message.
Investigation value:
- links return to original;
- provides return reason;
- carries returned amount and parties/agents as applicable.
A pacs.004 is evidence of a return transaction, not proof that the customer account has already been credited.
camt.053
Bank-to-customer statement message can support:
- settlement account reconciliation;
- corporate statement;
- transaction evidence.
Payments Canada publishes Lynx camt.053 specifications.
Internal events matter more than raw XML
A case platform should not force operations to read XML.
Parse relevant data into:
- payment summary;
- state timeline;
- parties;
- references;
- return reasons;
- related transactions.
Then provide raw message for expert review/audit.
7. Uncertain outcomes, duplicates and technical failures
Uncertain outcome is one of the highest-risk payment states.
Example
- channel sends payment;
- payment hub releases externally;
- network response is delayed;
- channel times out;
- customer presses pay again.
If the bank treats timeout as failure, duplicate payment can result.
Safe pattern
Use:
- idempotency key;
- durable payment ID;
- retry-safe gateway;
- state query;
- duplicate detection.
Customer message:
“Status is being confirmed. Do not resend.”
Duplicate classification
Possible duplicates:
Customer duplicate
Two genuine customer instructions.
Channel duplicate
Same request submitted twice.
Bank technical duplicate
Retry produced second external payment.
External duplicate
Network/participant anomaly.
Each has different liability and correction.
Investigation test
Compare:
- customer instruction count;
- bank payment count;
- external payment count;
- settlement count;
- posting count.
This simple matrix often reveals where duplication occurred.
| Layer | Count |
|---|
| Customer instructions | 1 |
| Internal payments | 2 |
| External settlements | 2 |
| Beneficiary credits | 2 |
This indicates bank/system duplication after one instruction.
Technical failure after settlement
If settlement completed but downstream posting failed:
- do not resend;
- repair downstream posting;
- reconcile settlement to customer ledger;
- communicate status.
Technical failure before release
If no external release occurred:
- correct/retry internally using same business instruction;
- preserve idempotency;
- do not create false new customer instruction.
8. Fraud, sanctions and legal escalation
Investigations often cross control functions.
Fraud
Signs:
- customer denies authorization;
- scam;
- account takeover;
- mule beneficiary;
- unusual beneficiary;
- rapid onward movement.
Immediate priorities:
- secure customer/account;
- stop unreleased transactions;
- identify all affected payments;
- send recovery requests;
- contact receiving-side fraud team;
- preserve evidence.
Payment investigation continues, but fraud operations may take case lead.
Sanctions
A sanctions case may involve:
- payment held before release;
- receiving bank asks for information;
- potential prohibited party;
- post-event match.
Do not “repair around” sanctions controls to achieve STP.
Operations supplies payment facts; compliance decides disposition under policy/law.
AML
A payment investigation may reveal:
- mule activity;
- structuring;
- unusual flows;
- suspicious counterparties.
The AML decision is separate from payment recovery.
FINTRAC reporting should be handled by the institution’s compliance process, not by payment operations guessing whether a transaction is reportable.
Legal orders and disputes
Investigations may intersect:
- court orders;
- garnishment;
- estate matters;
- fraud claims;
- customer complaints.
Case-management permissions should prevent unauthorized users from viewing or changing restricted legal information.
9. Case management, ownership and service levels
A spreadsheet can track ten cases. It cannot safely manage thousands of payment investigations.
The roles-and-SLAs diagram above assigns every case field below to an owner with a service level; no investigation should sit without both.
Case fields
Minimum:
- case ID;
- original payment ID;
- rail;
- amount/currency;
- customer;
- issue type;
- created time;
- priority;
- owner;
- external party;
- last action;
- next action;
- deadline;
- financial exposure;
- customer-impact status;
- outcome.
Priority
Do not prioritize only by amount.
Consider:
- fraud;
- vulnerable customer;
- payroll;
- house closing;
- regulatory deadline;
- sanctions;
- large financial exposure;
- ageing;
- repeat failure;
- widespread incident.
A CAD 1,500 payroll problem affecting a family may have more immediate customer harm than a well-collateralized corporate treasury query.
Service levels
Differentiate:
- acknowledgement SLA;
- first investigation SLA;
- external response target;
- customer update cadence;
- final resolution.
Do not promise a final resolution time controlled by another institution.
Ownership model
One accountable owner per case.
Specialist tasks may be assigned to:
- payments operations;
- fraud;
- compliance;
- treasury;
- technology;
- customer service.
The case owner is responsible for the next action and communication.
Handoffs
A handoff must include:
- exact question;
- evidence;
- urgency;
- required output.
“Please check” is not a controlled handoff.
10. Accounting, reconciliation and closure
A case is not closed because another bank replied.
It closes when:
- customer outcome is known;
- financial position is resolved;
- suspense cleared or formally transferred;
- corrective postings complete;
- external case closed;
- customer informed;
- root cause captured.
Financial exposure field
Track separately:
- original amount;
- amount at risk;
- amount provisionally credited;
- amount recovered;
- amount written off;
- fees/FX adjustments.
This avoids case notes becoming the accounting system.
Reconciliation break as investigation trigger
Example:
- Lynx settlement outflow exists;
- customer debit missing.
This is not necessarily customer non-receipt; it is an internal accounting break.
The reconciliation engine should open a case with evidence attached.
Investigation as reconciliation trigger
Example:
- receiving bank confirms return sent;
- return not found in bank ledger.
Investigation should create or escalate a reconciliation search.
Closure code
Use specific root-cause codes:
- customer error;
- beneficiary account closed;
- routing error;
- bank processing defect;
- external participant delay;
- duplicate;
- fraud;
- sanctions/compliance;
- no defect / beneficiary later confirmed;
- unresolved / legal.
Root-cause analytics are impossible if every case closes as “resolved.”
Post-incident learning
Repeated cases should drive change.
Metrics:
- cases per million payments;
- case rate by rail;
- top cause;
- mean time to first action;
- mean time to financial resolution;
- ageing;
- amount at risk;
- recovery rate for fraud;
- duplicate rate;
- repeat customer contact;
- automation opportunity.
11. Practical investigation scenarios
The scenarios in this section and elsewhere in the chapter are fictional teaching cases. Amounts, names, timestamps, responses and outcomes are illustrative; they are not reported transactions or evidence that a particular bank, participant or system behaved that way.
Scenario A: beneficiary says domestic wire missing
Customer: CAD 650,000 supplier payment.
Evidence:
- customer instruction valid;
- sanctions checks completed;
- Lynx payment settled;
- beneficiary claims non-receipt.
Investigator does not resend.
Actions:
- confirm exact beneficiary account transmitted;
- confirm Lynx settlement/reference;
- open interbank inquiry with receiving participant;
- ask whether funds are posted, in repair/suspense or returned;
- keep customer updated.
Receiving bank discovers beneficiary account number is valid but belongs to another legal entity due to customer master-data error.
Case becomes:
- misdirected payment/recovery;
- possible recall/return process;
- customer master-data remediation.
Scenario B: payroll item missing
Employer sends 2,000 AFT payroll credits.
One employee says unpaid.
File shows accepted.
Investigator:
- identifies item sequence;
- checks clearing/export;
- checks return file;
- finds account-closed return;
- confirms returned value posted to employer settlement arrangement;
- supplies item-level reason to payroll team.
The bank does not trace all 2,000 items.
Scenario C: Interac recipient cannot find transfer
Sender sees debit and completed status.
Recipient expected an email.
Investigator separates:
- payment/deposit state;
- notification;
- recipient contact details.
If Autodeposit was used, absence of an email message is not proof that funds did not deposit.
If fraud is alleged, case is escalated to fraud rather than treated as notification support only.
Scenario D: cross-border payment stuck
Canadian corporate sends USD supplier payment.
SWIFT message delivered to correspondent.
Beneficiary has no credit.
Investigation checks:
- UETR/tracker;
- nostro settlement;
- intermediary status;
- sanctions requests;
- beneficiary-bank receipt;
- charges;
- FX/value date.
Intermediary asks for beneficiary address clarification due compliance review.
The message was delivered; funds were not yet available to beneficiary.
This is why message status and funds status must be separate.
Scenario E: fictional post-launch RTR timeout design
Customer sends CAD 900 in a fictional post-launch test scenario. This does not imply that RTR is in production on the audit date.
Channel times out.
Internal event store shows payment accepted by exchange and settled.
No second payment is created.
Bank repairs channel status and confirms beneficiary posting.
Root cause:
- response delivery defect, not payment failure.
Customer experience:
- brief uncertain status;
- no duplicate loss.
Deeper operating practice: investigation design for real banks
A strong investigation function is designed around questions, evidence and actions, not around one generic “investigation status.”
The case platform should separate:
- what the customer claims;
- what internal systems prove;
- what external systems prove;
- what remains unknown;
- what action has been requested;
- what money has actually moved;
- what financial exposure remains.
This avoids a common failure: the case note says “beneficiary bank confirmed return” while the bank has not yet received the returned settlement and customer accounting is already adjusted.
Evidence confidence model
Not all evidence has equal strength.
A useful internal hierarchy is:
Level 1 — customer statement
- valuable trigger;
- not sufficient by itself to prove payment state.
Level 2 — internal application status
- useful;
- depends on whether application owns the relevant event.
Level 3 — gateway/network acknowledgement
- proves message/file acceptance or transmission stage;
- not automatically final settlement.
Level 4 — clearing/settlement evidence
- proves interbank financial state.
Level 5 — beneficiary posting confirmation
- proves customer availability at receiving side.
Level 6 — independent ledger/statement evidence
- verifies financial booking.
Case notes should state evidence level implicitly through precise wording.
Avoid:
“Payment received by beneficiary.”
Unless beneficiary posting is actually confirmed.
Prefer:
“Lynx settlement confirmed; beneficiary posting remains under inquiry.”
Investigation decision tree
For any customer inquiry:
- Find exact original payment.
- Check whether payment left the bank.
- If no: investigate internal rejection/repair.
- If yes: identify external acceptance.
- If rejected: explain/repair according to cause.
- If accepted: identify settlement.
- If not settled: identify queue/technical/liquidity cause.
- If settled: identify receiving institution.
- Check return evidence.
- If not returned: ask whether beneficiary was credited or payment is in receiving-side repair.
- Choose inquiry, recall, fraud recovery or accounting correction.
- Reconcile final outcome.
This sequence prevents premature external contact.
Case intake quality
A good intake form reduces investigation time.
Required data can include:
- customer/account;
- payment date;
- amount/currency;
- beneficiary;
- customer reference;
- issue description;
- expected outcome;
- urgency/business impact.
System should auto-populate:
- payment ID;
- rail;
- external reference;
- current state;
- settlement status;
- return status;
- related cases.
Do not ask customers to provide information the bank already owns.
Corporate-payment investigations
Corporate cases often involve ERP and file layers.
Example:
Supplier says invoice unpaid.
Investigator may need:
- ERP payment run ID;
- pain.001/file ID;
- bank file acknowledgement;
- item ID;
- bank payment ID;
- external payment;
- beneficiary statement evidence.
A corporate file can be accepted while one item is rejected.
Therefore investigation must support:
- file-level status;
- batch-level status;
- item-level status.
Payroll investigations at scale
Payroll requires special handling because thousands of payments may share:
- same file;
- same due date;
- same employer;
- similar amount.
If one employee reports non-receipt:
- search exact employee item;
- do not reopen entire file;
- verify return;
- verify account data;
- provide employer item-level evidence.
If 300 employees report non-receipt:
- switch from individual case model to incident/problem model;
- identify common route/receiving participant;
- avoid 300 duplicate external traces.
Problem management link
Recurring investigations should generate a problem record.
Example:
- 150 cases in two hours;
- same receiving institution;
- same payment product;
- all settlement confirmed.
Likely systemic issue.
The case platform should:
- link individual customer cases to incident;
- preserve individual financial state;
- publish common status;
- update customers consistently.
This reduces duplicated analyst work.
Investigation of missing incoming payments
Customer says:
“I was supposed to receive money.”
The bank may not have a transaction reference.
Investigator should ask:
- sender bank?
- amount/currency?
- sender reference?
- expected date?
- payment method?
Then search:
- incoming external reports;
- unapplied/suspense;
- rejected account matches;
- return activity.
Do not promise receipt if sending bank has only shown initiation screenshot.
Beneficiary unable to identify sender
Sometimes the payment posted, but remittance/reference is insufficient.
This is not missing money.
Case classification:
- payment credited;
- remittance/information issue.
Resolution:
- provide available remittance data;
- contact sending side if needed;
- improve structured remittance handling.
Wrong beneficiary investigations
Wrong beneficiary can arise from:
- customer selection error;
- tampered invoice;
- corporate master-data compromise;
- bank routing defect.
These have different ownership.
Customer error:
- recovery request;
- customer master-data correction.
Fraud:
- fraud escalation;
- urgent receiving-bank contact;
- mule analysis.
Bank defect:
- operational incident;
- customer remediation;
- root-cause fix.
Investigation should establish cause before liability conclusion.
Duplicate investigations
Duplicate cases should compare business intent.
Two payments with same amount/date are not automatically duplicates.
Check:
- customer instruction IDs;
- beneficiary;
- invoice/reference;
- authorization;
- timestamps;
- idempotency key.
A corporate may intentionally pay two identical invoices.
Duplicate classification requires evidence of one intended business event creating multiple payments.
Fee and charge investigations
Customer says beneficiary received less.
Possible causes:
- sending bank fee;
- intermediary charge;
- beneficiary bank charge;
- FX;
- partial return;
- beneficiary account deduction.
Investigator reconstructs:
- instructed amount;
- settlement amount;
- charge bearer;
- correspondent deductions;
- credited amount.
Do not label as missing payment if difference is explained by valid charges.
Foreign exchange investigations
Customer disputes exchange rate.
Evidence:
- rate offered;
- timestamp;
- rate acceptance;
- payment currency;
- amount;
- spread/fee disclosure;
- return rate if payment returned.
FX investigation may involve treasury/product, but payment case remains parent.
Investigation of “pending” statuses
A payment can remain pending because:
- future date;
- repair;
- sanctions review;
- fraud review;
- liquidity queue;
- external timeout;
- beneficiary-posting delay.
Customer-facing “pending” should ideally include a safe category.
Operations should not leave cases in generic pending without owner and deadline.
External communication protocol
A standardized request can include:
Case: INV-123
Original payment: PAY-456
Rail: Lynx
External reference: <reference>
Amount: CAD 125,000
Settlement: confirmed <timestamp>
Issue: beneficiary reports non-receipt
Requested action: confirm posting or reason for non-credit
Contact: payments investigations
The exact interbank communication channel depends on arrangement.
The principle is complete identity + one clear request.
Response interpretation
Receiving bank may respond:
- credited;
- account closed;
- wrong account;
- held for compliance;
- unable to identify;
- returned;
- return pending;
- no record.
Each response maps to next action.
“Returned” should trigger:
- search for actual return transaction;
- not immediate case closure.
Investigation timeline
A case timeline should show business events separately from notes.
Example:
09:12 customer inquiry received
09:13 payment PAY-456 identified
09:14 Lynx settlement confirmed
09:20 interbank inquiry sent
11:02 receiving bank: account closed, return initiated
11:30 pacs.004/return received
11:31 settlement inflow confirmed
11:35 customer credit posted
11:40 customer notified
11:45 reconciliation matched
11:46 case closed
This is audit-ready.
Structured notes
Avoid free-text-only case management.
Structured fields:
- state;
- reason;
- evidence;
- financial exposure;
- external response;
- next action.
Free text remains for context.
Structured data enables analytics.
Service-level design
Service levels should reflect control point.
Example categories:
Immediate
- suspected fraud;
- sanctions;
- duplicate high-value;
- payment at risk of unrecoverable onward movement.
Priority
- high-value beneficiary non-receipt;
- payroll;
- house closing;
- customer funds trapped.
Standard
- statement clarification;
- old return reference;
- fee query.
Response targets must not imply another institution is bound by bank’s internal target.
Investigation and complaint management
A payment investigation can become a formal complaint.
Systems should link but distinguish:
- operational case;
- complaint case;
- regulatory complaint deadline;
- compensation decision.
Closing operational case does not automatically close complaint.
Fraud recovery economics
Track:
- amount sent;
- amount reported fraud;
- amount frozen;
- amount returned;
- amount reimbursed;
- bank loss.
Example:
CAD 20,000 scam.
Receiving bank freezes CAD 7,000.
Customer reimbursed CAD 10,000 under bank decision.
Final bank exposure depends on recovery and reimbursement accounting.
This data should not be reconstructed from case notes later.
Sanctions investigation boundaries
Payments investigations provides:
- message;
- parties;
- account;
- routing;
- settlement state.
Compliance provides:
- screening decision;
- legal interpretation;
- release/block instructions.
Operations should never alter party data to avoid a match.
Evidence retention
Evidence can include:
- payment instruction;
- authentication;
- approval;
- message;
- external response;
- settlement report;
- statement;
- call log;
- email;
- case notes.
Retention must follow applicable bank, legal and regulatory requirements.
For PSPs subject to the RPAA, the Bank of Canada’s supervisory framework expects operational-risk and incident-response frameworks, material-incident reporting and supporting information when requested; the PSP must retain evidence sufficient to demonstrate those controls under its applicable requirements.
Access controls
Investigation platforms contain sensitive information.
Roles may differ:
- branch/customer service;
- payments operations;
- fraud;
- AML;
- sanctions;
- legal;
- technology.
A customer-service user may need case status but not full suspicious-transaction narrative.
Investigation quality assurance
Review samples for:
- correct transaction identified;
- evidence supports conclusion;
- no unsupported promise;
- financial action authorized;
- customer notified;
- correct root cause;
- settlement/ledger reconciled.
High-value or fraud cases may require secondary review.
Automation without false certainty
Automation can:
- collect evidence;
- identify likely state;
- draft inquiry;
- match return;
- calculate ageing.
Automation should not:
- infer settlement from weak signal;
- credit customer merely because recall response text says “processing”;
- close case with unresolved money;
- override sanctions/fraud decisions.
Metrics that matter
Volume alone is weak.
Better:
- cases per million payments;
- cases by rail;
- settlement-confirmed/beneficiary-not-credited cases;
- manual evidence steps per case;
- average first-action time;
- financial-resolution time;
- unresolved amount;
- ageing;
- repeat cases;
- automation rate;
- wrong-route cases;
- reopening rate.
Investigation root-cause matrix
| Root cause | Preventive improvement |
|---|
| Invalid beneficiary data | channel validation / confirmation |
| Stale corporate master | beneficiary governance |
| Duplicate retry | idempotency |
| Gateway timeout | state-query recovery |
| Missing remittance | structured data |
| Posting defect | ledger resilience |
| Receiving-bank delay | external escalation/process |
| Fraud | prevention + receiving-side intelligence |
| Manual error | workflow controls |
| Reference loss | data lineage |
End-to-end testing patterns
Test investigations with data seeded across systems.
Scenario 1: settled, no posting
- external settlement exists;
- receiving posting fails;
- case should identify correct owner.
Scenario 2: return already received
- customer asks non-receipt;
- system should surface return before sending inquiry.
Scenario 3: duplicate external payment
- one instruction;
- two settlements;
- case escalates bank incident.
Scenario 4: two intended payments
- two instructions;
- two settlements;
- should not flag duplicate.
Scenario 5: wrong UETR
- analyst enters wrong ref;
- system should not permit action until identity resolved.
Scenario 6: late external response after customer reimbursement
- returned funds should clear bank exposure, not double-credit customer.
Scenario 7: disaster recovery
- case store restored;
- no lost notes;
- open deadlines reconstructed.
Knowledge management
Investigation teams should maintain:
- rail-specific runbooks;
- contact matrices;
- return/reason-code guides;
- current rules;
- screenshots only as supplementary help;
- escalation tree.
Runbooks need version dates.
An old cutoff or obsolete rule in a runbook can create wrong customer advice.
Training model
New investigator should learn in this order:
- payment lifecycle;
- rail settlement model;
- transaction identity;
- evidence hierarchy;
- exception taxonomy;
- customer communication;
- accounting/reconciliation;
- fraud/compliance escalation;
- tooling.
Teaching message syntax before payment state creates operators who can read XML but cannot diagnose money movement.
Final operational principle
A good investigation answer is a short statement backed by a long evidence chain.
Example:
The payment settled to the receiving participant at 10:14. The beneficiary account could not be credited because it was closed. A return settled back at 12:02, and the customer was credited at 12:05. The case is financially reconciled.
Every part of that sentence is independently provable.
Investigation worksheets by rail
A practical academy chapter should leave the learner able to run a case. The following worksheets show what evidence to collect before escalation.
AFT / payroll worksheet
Confirm:
- file ID;
- originator;
- due date;
- item sequence;
- amount;
- beneficiary account/transit;
- file acceptance;
- item acceptance;
- return code;
- return date;
- customer ledger.
Questions:
- Was file accepted?
- Was item actually exchanged?
- Did receiving institution return?
- Was return matched?
- Was employer informed?
Do not trace the whole payroll when one item has a clear return.
PAD worksheet
Confirm:
- PAD agreement/authority;
- biller/collector;
- debit date;
- amount;
- transaction reference;
- return reason;
- customer dispute;
- reimbursement;
- collector position.
Questions:
- Is dispute about payment or mandate?
- Was debit returned?
- Was customer reimbursed separately?
- Is originator recovery outstanding?
Lynx worksheet
Confirm:
- customer instruction;
- account;
- beneficiary;
- amount;
- pacs message/reference;
- UETR where applicable;
- Lynx settlement evidence;
- receiving participant;
- pacs.004 return if any.
Questions:
- Did settlement occur?
- Is beneficiary non-credit receiving-side issue?
- Is payment misdirected?
- Is recall appropriate?
- Has returned value actually settled?
Cross-border worksheet
Confirm:
- payment instruction;
- FX;
- SWIFT/UETR;
- correspondents/intermediaries;
- nostro entry;
- charges;
- beneficiary bank;
- compliance requests;
- return.
Questions:
- Where was value last proven?
- Is message delivered but funds held?
- Is intermediary waiting for information?
- Did beneficiary bank credit?
- If return, what amount/currency?
The investigation “golden timeline”
For complex cases, normalize timestamps into one timeline.
Example:
09:00 customer authorized
09:01 bank accepted
09:02 sanctions cleared
09:03 external message sent
09:03:05 network acknowledged
09:03:10 settlement confirmed
09:07 receiving bank posted
11:30 customer inquiry
This can prove the customer’s non-receipt claim is stale or reveal a downstream issue.
Store original timezone plus normalized UTC to avoid daylight-saving confusion.
Evidence contradictions
Sometimes systems disagree.
Example:
- payment hub: failed;
- settlement report: settled.
Settlement evidence usually means payment hub status is wrong.
Response:
- do not resend;
- repair internal state;
- correct customer posting/report.
Another:
- channel: completed;
- external gateway: no record;
- customer debit exists.
Investigate whether channel incorrectly promoted status before release.
Contradictions should be high-priority because they imply control failure.
Case-to-incident threshold
Define thresholds for turning individual cases into incident.
Triggers:
- same root cause count;
- same participant;
- same channel/version;
- value concentration;
- repeated technical code.
Incident link lets one technical team fix common cause while each customer case preserves financial outcome.
Investigation staffing model
Coverage should match rail availability.
Batch payments:
Lynx:
- operating cycle coverage.
Always-on services:
It is acceptable for some specialist resolution to be on-call, but urgent fraud/financial integrity decisions need availability.
Operations handover
Shift handover should include:
- high-value open cases;
- fraud recovery;
- pending returns;
- unresolved settlement breaks;
- aged suspense;
- external response due;
- incident-linked cases.
Do not rely on inbox.
Customer update discipline
Even when no new external response:
- state what remains known;
- state what is pending;
- avoid speculation.
Example:
“We have confirmed the payment settled to the receiving institution. We are waiting for confirmation of beneficiary posting.”
This is more useful than:
“We are still investigating.”
Root-cause closure criteria
Case outcome and root cause differ.
Outcome:
funds returned.
Root cause:
corporate beneficiary master record outdated.
Both should be captured.
Otherwise the same problem recurs.
Knowledge article from cases
Repeated case type should produce an internal guide:
- symptoms;
- evidence;
- likely cause;
- safe checks;
- escalation.
But guide should not bypass live rule/reference validation.
Investigation control failure examples
Failure 1: Wrong transaction selected
Operator sends recall for another CAD 10,000 payment.
Prevention:
strong identity + confirmation.
Failure 2: Recall marked recovered
Customer credited before return.
Prevention:
separate case status/financial status.
Failure 3: Timeout resent
Duplicate settlement.
Prevention:
idempotency/status reconstruction.
Failure 4: Fraud case routed standard
Recovery opportunity lost.
Prevention:
risk-based prioritization.
Failure 5: Case closed with suspense
Financial break remains.
Prevention:
closure requires accounting/recon check.
Audit checklist
Auditor/reviewer should be able to answer:
- Why was case opened?
- Which payment?
- What state was proven?
- Which source proved settlement?
- Which external requests sent?
- What responses?
- What financial actions?
- Who approved?
- What customer told?
- What root cause?
- Was reconciliation complete?
Implementation acceptance tests
A case platform is not ready until it can demonstrate:
- search exact payment;
- show state timeline;
- show external settlement;
- link return;
- prevent duplicate recall;
- restrict manual financial action;
- reopen on late response;
- preserve case through DR;
- report ageing/value;
- export audit trail.
Practitioner drill: from customer statement to provable answer
A customer says, “the payment disappeared.”
An investigator should turn that sentence into a sequence of factual questions:
- Which exact payment?
- Was the customer account debited?
- Did the bank release it?
- Did the external rail accept it?
- Did settlement occur?
- Was it returned?
- Did the receiving institution apply it?
- Is any corrective action already in progress?
Only then should the investigator choose an action.
This approach is reusable across every rail.
Investigation data dictionary
A production case platform benefits from a common vocabulary:
| Field | Meaning |
|---|
| OriginalPaymentId | Bank’s immutable payment identity |
| ExternalReference | Rail/network identity |
| CaseType | inquiry, trace, recovery, duplicate, posting, fraud |
| ProvenState | Highest financial state supported by evidence |
| UnknownQuestion | What remains unresolved |
| FinancialExposure | Amount currently at risk |
| RequestedAction | Information or corrective action requested |
| ExternalResponse | Counterparty response |
| CorrectivePaymentId | Return/recovery identity |
| CustomerRemediation | Credit/refund/communication |
| RootCause | Why exception occurred |
| ClosureEvidence | Proof that financial state is resolved |
Without UnknownQuestion, cases tend to accumulate notes without a clear objective.
Business analyst workflow specification
For a “beneficiary non-receipt” case:
Precondition
- original payment uniquely identified.
System automatically retrieves
- instruction;
- authorization;
- external references;
- settlement;
- return status;
- ledger posting.
Decision
- if never released → internal case;
- if externally rejected → reject handling;
- if settled and not returned → interbank inquiry;
- if returned → customer/accounting confirmation;
- if fraud indicator → fraud escalation.
Completion
- beneficiary status known or return/recovery concluded;
- customer informed;
- ledger/reconciliation complete.
This is a much stronger requirement than “create an investigation screen.”
Investigation API concepts
An API can expose:
GET /payments/{id}/timeline
GET /payments/{id}/related-transactions
POST /cases
POST /cases/{id}/inquiries
POST /cases/{id}/recalls
GET /cases/{id}/financial-exposure
The exact architecture varies, but the separation of read evidence and financial action is valuable.
Case security acceptance criteria
- customer-service role cannot create high-value return;
- fraud role can flag/coordinate but accounting action uses approved path;
- payments operator cannot alter original settled event;
- all manual actions logged;
- sensitive compliance notes role-restricted;
- audit export immutable.
Investigation failure-injection test
Simulate:
- acknowledgement lost;
- external response delayed;
- return arrives before inquiry response;
- case owner goes offline;
- ledger posting delayed;
- system restored from backup.
The case must converge to one correct financial outcome.
“No external inquiry needed” cases
Do not waste interbank capacity when evidence already proves:
- payment rejected internally;
- customer debit duplicated internally;
- payment was already returned;
- recipient issue is notification-only;
- statement narrative confused customer but credit exists.
An investigation platform should suggest this based on state.
“Urgent external contact” cases
Prioritize:
- fraud with potential recoverable funds;
- duplicate high-value payment;
- misdirected high-value payment;
- settlement confirmed but beneficiary cannot be credited and deadline/risk is material;
- systemic participant issue.
Closure statement template
A high-quality closure note can state:
Original payment:
Proven settlement state:
Exception cause:
Corrective action:
Financial outcome:
Customer outcome:
Reconciliation:
Root cause/remediation:
This makes closed cases reusable as operational knowledge.
Investigation failure-mode matrix
| Symptom | Likely evidence needed | Do not assume |
|---|
| Beneficiary non-receipt | settlement + receiving-bank posting | sending-bank debit proves receipt |
| Customer sees debit twice | payment count + ledger count | two external payments exist |
| Transfer notification missing | service/payment status | money did not move |
| Cross-border message delivered | nostro/intermediary/beneficiary evidence | funds reached beneficiary |
| Return promised | returned settlement | money already recovered |
| Timeout | state query/idempotency | payment failed |
| Payroll item missing | item-level return/trace | whole file failed |
| Reconciliation break | independent source comparison | customer complaint required |
Investigation requirement examples for architects and developers
A case platform should provide a read-only payment truth view that cannot be altered from the case screen. The view should assemble:
- original instruction;
- approval;
- payment timeline;
- external references;
- settlement;
- ledger;
- related returns;
- existing cases.
Financial actions such as return creation, customer credit or manual adjustment should be separate controlled commands.
That separation reduces accidental mutation of evidence.
Event sourcing benefit
An immutable event history is particularly useful for investigations.
Instead of:
status = RETURNED
the system retains:
09:01 AUTHORIZED
09:02 RELEASED
09:02:05 SETTLED
10:30 INQUIRY_OPENED
11:40 RETURN_RECEIVED
11:41 CUSTOMER_CREDITED
The current status can be derived, but history remains.
Investigation search design
Search should support:
- payment ID;
- account;
- amount range;
- date range;
- beneficiary;
- UETR/external reference;
- file/item ID;
- return ID;
- case ID.
Search results should display enough context to avoid selecting wrong transaction.
For common amounts, include:
- beneficiary;
- channel;
- exact timestamp;
- reference.
Investigation communications audit
Every external contact should be stored as:
- sent/received;
- institution;
- timestamp;
- channel;
- reference;
- content/attachment;
- linked action.
If a second team opens same case, it should immediately see what was already asked.
Case SLA design example
For urgent fraud:
- triage immediately;
- recovery contact immediately;
- customer update quickly;
- final resolution depends on recovery.
For ordinary beneficiary trace:
- acknowledge;
- reconstruct state;
- contact receiving side only if necessary;
- update on response.
An SLA should control bank activity, not falsely promise another institution’s response.
Investigation knowledge check
A Lynx payment settled but beneficiary bank cannot post because account is closed. Is the payment missing?
No. Settlement is proven; the issue is beneficiary application/return.
A customer has a successful debit but no external reference. What is the first question?
Whether the bank released the payment at all.
A SWIFT message has delivery confirmation. Is beneficiary paid?
Not necessarily. Message movement and funds/account posting must be distinguished.
A return arrives after customer provisional credit. What must be checked?
Whether returned value should clear bank exposure instead of crediting customer again.
Chapter 68 practical takeaway
A high-quality investigator should be able to produce one sentence containing:
- original payment;
- proven external state;
- unresolved question;
- next action.
If the sentence contains speculation, more evidence is required.
Full end-to-end investigation case
A fictional corporate, Cedar Manufacturing, sends CAD 1.25 million to a Canadian supplier through a domestic high-value wire.
09:10 — Corporate user creates payment in online banking.
09:12 — Second approver releases it.
09:13 — Bank validates account, entitlement, beneficiary data, fraud and sanctions controls.
09:14 — Payment is released to Lynx.
09:14 — Lynx settlement is confirmed.
10:45 — Supplier says it has not received funds.
A weak investigation sends “please trace” immediately.
A strong investigation first retrieves:
- payment ID;
- exact beneficiary account transmitted;
- pacs.008 business data;
- Lynx settlement reference;
- customer debit;
- any return.
No return exists.
The investigator sends one precise receiving-bank inquiry:
- settled payment reference;
- amount;
- beneficiary;
- request to confirm posting or reason for non-credit.
Receiving institution replies:
- funds were received;
- beneficiary account is open;
- payment is in repair because the customer instruction carried a beneficiary name inconsistent with internal account information;
- additional confirmation is required.
The sending bank now knows:
- payment did not fail;
- settlement is not missing;
- a resend would create a duplicate;
- receiving-side application is the unresolved step.
Cedar is told:
“We have confirmed that the payment settled to the receiving institution. The receiving institution is reviewing the beneficiary application, and we are following up on the posting.”
Later, receiving bank credits beneficiary.
Case closes only after:
- beneficiary credit confirmation;
- customer update;
- no return expected;
- settlement/customer ledger reconciliation remains matched.
Root cause review identifies stale supplier master-data naming.
Corrective action:
- Cedar updates supplier record;
- bank considers stronger beneficiary-data validation.
This one case demonstrates the complete method:
identity → evidence → state → owner → action → financial closure → prevention.
Advanced review questions
- If the receiving bank had returned the funds instead, which event would prove recovery?
- If Cedar had already resent the payment, how would duplicate handling differ?
- If the beneficiary details were altered by business-email compromise, which team would take lead?
- If the customer debit were missing despite Lynx settlement, what accounting exposure would exist?
- If the inquiry response arrived after a return had already settled, which evidence takes priority?
The answer in every case comes from the financial event history, not from the last free-text note.
Investigation patterns for operations, developers and testers
An investigation function is strongest when the same business state is visible to every role but each role can act only within its authority.
Operations view
- payment state;
- external references;
- cases;
- messages;
- next action.
Developer/support view
- correlation IDs;
- event timestamps;
- integration responses;
- retry/idempotency evidence.
Reconciliation view
- settlement;
- ledger;
- unmatched items;
- corrective events.
Customer-service view
- safe customer-facing status;
- last update;
- expected next step.
The views should share one source of payment truth.
Investigation correlation architecture
A practical correlation model stores a canonical payment ID and maps every external/internal identifier to it.
Canonical payment PAY-123
├─ channelRequestId
├─ fileId/itemId
├─ messageId
├─ UETR/external reference
├─ settlement reference
├─ ledger reference
├─ return reference
└─ case IDs
This allows a case opened from a statement entry to find the same transaction that an operations user finds from a UETR.
Handling missing or damaged references
Sometimes the ideal key is absent.
The investigator may use controlled secondary matching:
- amount;
- currency;
- date/time window;
- account;
- counterparty;
- direction.
But the system should label the match as candidate until confirmed.
For high-value corrections, candidate matching should never be enough to release money.
Investigation evidence provenance
Every displayed fact should know its source.
Example:
Settled at 10:14:03
Source: Lynx settlement event
Received: 10:14:04
Correlation: UETR ...
Another:
Beneficiary credited
Source: receiving-bank response
Received: 11:22
Case message: MSG-882
Source provenance reduces arguments about which dashboard is authoritative.
Managing contradictory customer and system evidence
Customers can provide screenshots that appear inconsistent with bank records.
Do not dismiss either side.
Example:
- customer screenshot shows “completed”;
- payment hub shows external reject.
The investigation may reveal the channel incorrectly mapped “submitted” to “completed.”
Outcome:
- customer remediation;
- product/UI defect;
- no interbank trace required.
The complaint is valid even if no money settled.
Investigation of delayed beneficiary posting
Settlement can be complete while beneficiary credit is delayed due:
- account validation;
- compliance review;
- internal receiving-bank repair;
- account restriction;
- posting outage.
The sending bank generally cannot resolve the receiving bank’s internal cause directly. It can:
- provide complete information;
- request status;
- maintain customer communication;
- initiate return/recovery only when appropriate.
Investigation of old historical payments
Historical inquiries require:
- archived payment events;
- statements;
- messages;
- settlement evidence;
- retention-compliant case search.
A platform that only keeps online data for a few months forces manual archive work.
Retention strategy should be aligned to legal/regulatory/internal requirements.
Investigation analytics and product improvement
A well-coded case taxonomy can identify:
- one receiving institution causing disproportionate non-credit cases;
- one corporate channel causing duplicate submissions;
- one beneficiary field causing repairs;
- one release version causing timeouts;
- one return code increasing sharply.
Investigation data is therefore a product-quality input, not just an operations workload.
Designing “next best action” safely
A case system can recommend:
Settlement not found → check external acceptance
Settlement confirmed + no return → beneficiary inquiry
Return settled + customer not credited → accounting action
Fraud indicator → urgent fraud escalation
The recommendation should never bypass authorization.
It reduces analyst search time while preserving human control for high-risk actions.
Case closure versus problem closure
An individual customer case can close after financial resolution.
The underlying problem may remain open.
Example:
- customer credited;
- root cause is payment hub retry defect;
- defect not yet fixed.
Case: closed.
Problem/incident remediation: open.
Keeping the distinction prevents “customer fixed” from being mistaken for “system fixed.”
Investigation quality scorecard
A quality reviewer can score presence—not subjective outcome—of:
- correct original payment;
- evidence-backed state;
- appropriate external contact;
- no duplicate communication;
- correct financial action;
- customer update;
- reconciliation;
- root cause;
- audit completeness.
This creates coachable operational quality without ranking employees on arbitrary case complexity.
Advanced testing catalogue
Add scenarios:
- external settlement arrives after internal timeout;
- two returns reference one original payment;
- external participant supplies wrong reference in response;
- customer has two same-amount payments seconds apart;
- case opened before payment reaches final state;
- customer closes account while return pending;
- fraud case and normal investigation opened simultaneously;
- external response contradicts settlement evidence;
- case SLA expires during participant outage;
- archive data required for old payment.
For each test, assert the platform never loses original identity and never creates a corrective financial action twice.
Chapter 68 final practitioner checklist
At case opening:
- unique payment identified;
- customer question recorded;
- current proven state available.
During case:
- unknown question explicit;
- owner assigned;
- financial exposure visible;
- external communication centralized.
At closure:
- final state proven;
- customer outcome complete;
- accounting/reconciliation complete;
- root cause coded;
- related incident/problem linked;
- evidence retained.
12. Implementation, testing and authoritative references
Investigation-platform capabilities
A mature platform should provide:
- transaction search;
- state timeline;
- message/file viewer;
- settlement evidence;
- customer ledger;
- related payments;
- external communication;
- templates;
- SLA/ageing;
- financial exposure;
- workflow routing;
- maker-checker for financial action;
- document/evidence storage;
- audit history;
- reporting.
Automation candidates
Automate:
- state reconstruction;
- known return matching;
- duplicate detection;
- status lookup;
- reminder/escalation;
- reference validation;
- standard customer updates.
Keep human judgment for:
- fraud narratives;
- sanctions/legal decisions;
- ambiguous beneficiary claims;
- compensation;
- high-risk manual corrections.
Test scenarios
Test:
- payment never released;
- external reject;
- settlement confirmed but beneficiary non-credit;
- returned payment;
- duplicate;
- partial recovery;
- unknown reference;
- wrong amount;
- timeout;
- delayed response;
- case reopened;
- multiple cases on one payment;
- fraud escalation;
- sanctions escalation;
- customer provisional credit;
- external response after case closure;
- reconciliation break auto-case.
Authoritative references
This application uses JavaScript for the full interactive experience. This text summary is served for accessibility and search indexing.