Catch payment problems at the door, not in the queue.
Clearway: how Wio can find, rank and resolve payment issues earlier, and keep every customer at ease while it happens.
Stop adding people to the end of the pipe. Fix the three places where manual work starts.
Payments that need a human sit in silence. Operations and Compliance work across many systems, and the customer finds out last.
Trace every held payment end to end by its tracking reference (UETR), and size the causes before designing anything.
Bad data is caught too late. Screening has no memory. Nobody owns the payment journey end to end.
Clearway: Prevent, Prioritise and Inform on one shared timeline, using rules, machine learning and an AI copilot where each fits best. People keep every decision. About half of manual hours freed at my assumed volumes.
Discover, Design, Pilot, Scale. First 30 days: a baseline, checks at entry, one-question requests, and proactive updates.
In plain words, an international payment is a parcel crossing several borders.
We pack it, label it and send it. It then passes checkpoints we do not run. If the address is wrong, the label is vague, or the sender's name looks like someone on a watch list, the parcel goes on a shelf. Someone then writes to the sender to ask what is inside. Meanwhile the sender sees "processing" and wonders where their money went.
Everyone pays for a held payment. Only the customer pays in anxiety.
Customers
Experience, trust, clarity, effort
- Money in limbo, with no reason and no time
- Vague requests for "documents", sometimes twice
- Has to contact support to learn anything
- SMEs risk late fees and supplier trust
Operations and Compliance
Effort, complexity, rework, risk
- Most sanctions alerts turn out to be false positives
- One case means checking five or six systems
- Free-text questions lead to partial answers and second rounds
- Alert fatigue raises the chance of missing a true hit
The business
Cost, growth, revenue, risk, brand
- Cost grows with every new customer if the fix is headcount
- Slower settlement and more support tickets
- A brand built on word of mouth and high NPS is at stake
- Regulatory exposure if a true hit slips through
The constraint that shapes everything: we cannot loosen controls. The answer has to be smarter controls, not fewer controls.
What I know, and where I am filling gaps
What is public
| Customers | 270k+ personal, 120k businesses, 10k+ families |
| Scale | About AED 61bn in assets, AED 1.24bn revenue (2025) |
| Cross-border | A global clearing partner for USD, EUR and GBP |
| Rules | New UAE AML law in force since October 2025, including a ban on tipping off |
| Industry | About 72% of Swift payment exceptions come from data and format errors |
What I assumed
| Assumption | Value |
|---|---|
| International payments sent per month | 350,000 |
| Share needing a person | 6% → 21,000 cases |
| Mix: sanctions, data, status, recon, other | 45 / 25 / 15 / 10 / 5 % |
| Handling time per case, including questions | 25 min → 8,750 h |
| Held payments that trigger a support contact | 40% |
I would replace every one of these in the first two weeks. The conclusion holds across a wide range, and the prototype lets us test that live.
Before designing anything, I would trace every held payment end to end.
| What I would look at | The question it answers | Where it likely lives |
|---|---|---|
| Payment events, joined by UETR | Where do payments stop, for how long, and who touched them? | Payment hub, core banking, gpi tracking, status and return messages |
| Exception reasons and repairs | Which causes dominate, by corridor, segment and channel? | Payment operations case tool, reject and return codes |
| Screening alerts and outcomes | False-positive rate by rule and name pattern, and repeat alerts on the same pair | Screening system audit log, analyst case notes |
| Requests for information | Which questions get partial answers, and how many rounds per case | Case notes, in-app messages, email |
| Support contacts | How many customers ask before we tell them? | CRM and chat tags, app reviews |
| Transfer form behaviour | Which fields get edited, fail checks or cause drop-off? | Product analytics |
| Reconciliation breaks | What share is just fees, and how long do breaks stay open? | Reconciliation tool, partner bank statements |
| People | The workarounds and judgement calls that data misses | Shadow 10 analysts for a shift. Interview 8 to 10 SME and freelancer customers. |
Six questions I would ask in week one
Compliance. Of last month's false positives, how many could we have closed with data we already held? What stops us remembering a cleared beneficiary?
Operations. Walk me through the last 10 cases you closed. Where did you wait, and on whom?
Engineering. Do we store the UETR and every status update for every payment in one place we can query?
Product. Which transfer-form fields get edited or fail most, and what is checked before submit?
Customer support. What is the first thing a customer asks about a held payment, and what can't you answer?
Treasury and partners. Which corridors and partner banks cause the most delays, returns and fee gaps?
Patterns I would look for
- The few causes that make up most of the volume
- The same customer and beneficiary flagged again after being cleared
- False positives clustered on Arabic and South Asian name spellings
- First-time beneficiaries and customers in their first 90 days
- Weekend and cut-off-time effects
- Cases needing more than one round of questions
- Customers contacting us before we contact them
- Analysts taking very different times on the same alert type
Three root causes. Each one survives because it is rational for someone.
01Problems are caught downstream
Wrong IBANs, vague purposes and missing documents enter at the form. They are caught later, by screening, a partner bank or the receiving bank, when fixing them costs the most.
02Screening has no memory
Every payment is screened from scratch. Name spellings collide. Analysts lack the identifiers they need in one view, so they ask the customer.
03Nobody owns the whole journey
A payment's status is split across the app, payment hub, screening, tracking, reconciliation and CRM. Each team clears its own queue. The customer learns last.
If these hold, the fix is not more people. It is checks at entry, memory in screening, and one owner of the payment from submit to arrival.
Every piece exists somewhere. Nobody has joined them into one journey.
| Capability | Global leaders | In the UAE | The lesson for Wio |
|---|---|---|---|
| Check the name before sending | UK Confirmation of Payee runs about 1.9 million checks a day. Verification of Payee is now required for euro transfers. | Aani pays by mobile number, so fewer IBANs are typed. Name checks on IBANs are still emerging. | Validate account and name at submit, not after release |
| Track every payment | Wise shows every step. 77% of its transfers arrive in under 20 seconds. | Mashreq was the region's first bank on Swift gpi, with tracking in its app. | Make status visible by default, so customers don't have to ask |
| AI on screening alerts | HSBC reports 60% fewer false positives and 2 to 4 times more financial crime found. | Emirates NBD automated its screening-alert investigations. | Measure fewer false positives and more true hits together |
| Trust known patterns | Wise skips extra steps for trusted recipients. | Mostly handled case by case. | Remember cleared beneficiaries and answers already given |
Where Wio can lead: incumbents bolt these on one by one. A cloud-native bank can join prevention, triage and customer messaging on one platform.
Clearway: three layers on one shared timeline
Prevent
Fixes root cause 01
- Checks while the customer types: IBAN, bank code, account and name
- Purpose suggested from history and the invoice
- Invoice asked for up front, only when a payment is risk-flagged
Prioritise and resolve
Fixes root cause 02
- One queue, ranked by risk, value, deadline and customer impact
- Memory of cleared beneficiaries, with expiry
- A copilot that gathers evidence and drafts. A person decides
- Automatic chasing of partner banks
Inform
Fixes root cause 03
- A parcel-style tracker for every payment
- Every hold says what, next step and by when
- One request, as a checklist, answered once
- Updates sent before the customer has to ask
Machines gather, rank and draft. People decide. Customers always know.
The cheapest investigation is the one that never opens.
Real checks. The IBAN checksum and bank-code rules catch typos instantly, before the payment leaves.
One-tap fixes. We suggest the saved IBAN, the likely purpose and the invoice, rather than just showing an error.
Friction only where it pays. We ask for more only when risk is high, and A/B test the impact on first-send conversion.
Rank by real risk, remember what we know, and let a copilot do the gathering.
Ranking
priority = 0.40 risk + 0.25 value + 0.20 deadline + 0.15 customer impact
Operations and Compliance set the weights together and review them monthly. A likely true match always goes to the top.
Smarter screening
- A cleared customer and beneficiary pair is not flagged again until the list or the details change
- Matching that understands name spellings and checks date of birth, nationality and registration
- A model that ranks alerts first, and closes only the safest ones after it has proven itself
Investigator copilot
- Builds the case file: KYC, history, past decisions, tracking
- Drafts the decision rationale with its evidence
- Drafts the customer question in plain language
- Read-only. It cannot release, reject or message anyone
Guardrails that do not move: a person signs off every decision, everything is logged, messages on likely true matches are locked to neutral wording, models are validated by Compliance, data stays in the UAE, and true-hit detection is tested continuously.
Uncertainty hurts more than waiting. Show the journey and ask once.
People tolerate a wait far better when they know why and for how long. Each screen gives a status, a time, and at most one question. Wording is written with UX writing and Compliance in English and Arabic, and sensitive reviews only ever use approved neutral text.
Rules where the answer is exact, ML where we rank, AI where we read and write
| Problem | Approach | What it does | Who decides |
|---|---|---|---|
| Typos and format errors | Rules: IBAN checksum, bank code and country checks | Exact and explainable, needs no training data | Customer fixes with one tap |
| Purpose and documents | Classifier on payment history, plus document AI that reads invoices | Suggests the purpose and checks invoice amount and reference | Customer confirms |
| Name matching | Spelling-aware fuzzy and phonetic matching, plus secondary identifiers | Handles Arabic and South Asian name variants without missing true hits | Analyst reviews hits |
| Which alert first | Gradient-boosted model trained on past analyst decisions, with a reason shown for every score | Ranks alerts by false-positive likelihood. Never closes one by itself in phase 1 | Analyst |
| Which payment will stall | Time-to-credit model by corridor and partner bank | Flags a delay before the customer notices, and drafts the chase | Operations |
| Case file and messages | LLM copilot with read-only tools and search over case history and policies | Gathers evidence, drafts the rationale and the customer question in English and Arabic | Analyst edits and approves |
| Reconciliation breaks | Rules plus anomaly detection on fee patterns | Clears known fee gaps and surfaces the odd ones | Operations reviews outliers |
The line I would not cross: no model or LLM makes a sanctions decision. Every model is tested on past cases before it touches the queue, then monitored for drift and for any drop in true-hit detection.
How it is built: an event backbone, a case layer, and intelligence on top
Across every layer: tracing and alerting, access control, model evaluation, and data kept in the UAE. This is illustrative. In practice I would fit it to Wio's existing cloud platform rather than add new tools.
I built it, so we can discuss decisions rather than slides.
What it shows
- Prevent: a real IBAN checksum catching a typo, with one-tap fixes
- Prioritise: a ranked queue, a copilot case file, and clearance that stays locked until the analyst confirms
- Guardrail: on a likely true match, the copilot cannot message the customer
- Inform: the customer's screen updates the moment the analyst acts
- Impact: every assumption is a slider
- How it is built: the stack, the AI uses and the guardrails
Sample data. A guided tour walks through it in ten steps.
A cross-functional build, with every trade-off made on purpose
Who contributes
| Engineering | Shared timeline, validation services, case tools |
| Data science | Ranking, matching, experiments |
| Design and UX writing | Tracker and messages, English and Arabic |
| Behavioural science | Defaults, waiting psychology, nudges |
| Compliance | Memory policy, model validation, approved wording |
| Operations and support | Playbooks, outcome labels, quality checks |
Trade-offs
| Tension | My call |
|---|---|
| Speed vs safety | Rank before auto-close. True-hit detection is a guardrail, never traded. |
| Friction now vs holds later | Ask more only when risk is high, and test it |
| Build vs buy | Buy the rails (validation, partner messaging). Build the timeline and ranking, which are Wio's edge. |
| Transparency vs tipping off | Always share status. Share reasons only through approved wording. |
| AI power vs explainability | The copilot drafts with evidence. Rules and people decide. |
Measure the payment, not the team
Straight-through rate
Share of international payments completed with no manual touch
Time-to-money when held
Median and slowest-10% time from submit to arrival, for payments a person touched
Drivers
- Exceptions per 1,000 payments
- Alerts per 1,000 and false-positive rate
- Handling time
- Question rounds per case
- Share where we notified first
- Support contacts per 1,000
Guardrails that must not move
- True-hit detection
- Quality-check disagreement
- Regulatory deadlines met
- Fraud and return rate
- Form completion rate
Discover → Design → Pilot → Scale, with a gate at each step
Discover
- Pull 90 days of held payments
- Size the causes and build a baseline
- Shadow analysts, interview customers
Design
- Entry checks and message templates
- Ranking weights agreed with Compliance
- Memory policy drafted
- Copilot tested on past cases
Pilot
- One corridor and one segment
- A/B test the entry checks
- Copilot shadows, then assists
- Proactive updates switched on
Scale
- All corridors and incoming payments
- Auto-close only the safest, proven lane
- Arabic messaging, domestic rails
- Hand over to the owning teams
What I would do first, and why: the baseline, the entry checks and proactive updates. They touch the most payments, need no change to screening policy, carry the least regulatory risk, and give us the measurement everything else depends on.
One dashboard, one rhythm, clear owners
Rhythm
- Weekly, 30 minutes: held-payments review with Operations, Compliance, Engineering, Product and Support, on one dashboard
- Every two weeks: experiment review covering what shipped, what moved and what we stop
- Monthly: ranking and model review with Compliance
Ownership
- One named owner for time-to-money, not just for queues
- A decision log for every policy change
- Analysts record outcomes when they close a case, so the models improve without extra work
What I would own
- The baseline and cause sizing
- Shadowing and customer interviews
- The entry-checks spec and pilot success criteria
- The test set that proves the copilot and ranking model before go-live
- A weekly impact update to the CEO Office
Stronger controls without more bureaucracy: every guardrail lives inside the workflow. The confirmation step, the locked wording and the quality sample all happen in the case, never as an extra form.
What would change my mind, and what I considered instead
If the data says otherwise
| Sanctions is not the biggest cause | Re-order around whatever is |
| Compliance cannot approve the memory | Lean on better identifiers and copilot speed |
| Entry checks hurt conversion | Apply them only to risk-flagged payments |
| The copilot is wrong or vague | Keep it in shadow mode and grow the test set |
| No UETR history exists today | Start capturing it now, and baseline from case tools meanwhile |
Alternatives I considered
- Outsource first-level review. Adds capacity but keeps cost rising with volume, and fixes no cause.
- Only re-tune the screening system. Fewer false positives, but customers still can't see anything.
- Full automation now. Too much regulatory risk before we have evidence.
- Replace the case management system. Slow. A shared timeline plus a thin console delivers value in weeks.
The single biggest risk is that the real causes look different from my assumptions. That is why Discover comes first and has a gate.
I have built each part of Clearway before, in other high-stakes systems.
Shell, through Wipro
A Kafka pipeline carrying 115 GB a day from 200+ offshore stations with zero data loss. Bad records were quarantined with context for replay, which cut production incidents by 25%.
The same pattern as one timeline per payment, with held items that can be fixed and released
GeneCart, NYU
An AI agent limited to a fixed set of least-privilege tools, with a person holding final authority over every change to research data.
The same guardrails as the investigator copilot
NYU research platform
Raised answer quality 40%, graded on held-out test sets and re-tested on every change. Cut response time from 450 ms to under 100 ms at 3,000+ requests a second, with 99.9% uptime.
How I would build and prove the ranking model and copilot
Shell vendor portal
Replaced a manual request queue with self-service for 500+ vendors. Support tickets fell 35% and service requests fell 45%.
The thinking behind the customer tracker and one-tap answers
And I built this prototype end to end within the task window. I enjoy finding the root cause with the people who run the process, then shipping something that measurably removes the work.
Fewer investigations. Faster answers. No customer left wondering.
Which of my assumptions would you challenge first?