International Payments Ops Workflow Redesign
Role
Everything - Program-level influencing, strategic research
Duration
Initial program kick off – 4 weeks,
part time; Lean research – 3 weeks
part time; Lean research – 3 weeks
Organisation type
Large org - Big 4 Bank
Project year
2023
Context
Program-level
• There was a large bucket of money put aside by our Payments Domain leadership to increase traceability, speed and data-richness for the International Payments portfolio.
• I lead a cross-functional team ranked Program priority for over 30+ complex, interdependent International Payments use cases that spanned Business, Personal, Ops and Wholesale.
• The priority we decided would determine how we’d divvy up the money, sequence the use cases AND still meet regulatory obligations.
• I lead a cross-functional team ranked Program priority for over 30+ complex, interdependent International Payments use cases that spanned Business, Personal, Ops and Wholesale.
• The priority we decided would determine how we’d divvy up the money, sequence the use cases AND still meet regulatory obligations.
Project-level
Our International Payments ops teams used 6 systems that presented the following challenges:
• Legacy tech = high development overhead for new functionality – affected a key exec scorecard metric.
• Lack of payment validation checks = $$$ losses – high value payments would be sent to the wrong recipient with no guarantee of retrieval.
• Unnecessary manual work = higher FTE head count - e.g. data was sometimes incorrectly ingested when passed between systems so required manual intervention.
• Difficulty cross-skilling or utilising resources across ops teams - ops systems are all very different.
• Legacy tech = high development overhead for new functionality – affected a key exec scorecard metric.
• Lack of payment validation checks = $$$ losses – high value payments would be sent to the wrong recipient with no guarantee of retrieval.
• Unnecessary manual work = higher FTE head count - e.g. data was sometimes incorrectly ingested when passed between systems so required manual intervention.
• Difficulty cross-skilling or utilising resources across ops teams - ops systems are all very different.
Design approach
Sell in Discovery. 3rd time's a charm.
I attempted to sell in Discovery 3 times.
For the 2nd attempt: I met the Senior Product Owner, Product Owner and Lead Business Analyst to walk them through why Discovery was important + how it worked. They communicated that their top 2 priorities were to meet compliance deadlines and ensure the backend architecture was future-proofed.
I revised my pitch with a peer, and went back to them with something along the lines of:
For the 2nd attempt: I met the Senior Product Owner, Product Owner and Lead Business Analyst to walk them through why Discovery was important + how it worked. They communicated that their top 2 priorities were to meet compliance deadlines and ensure the backend architecture was future-proofed.
I revised my pitch with a peer, and went back to them with something along the lines of:
"If we want to future proof the architecture, we need to know the future state design is because the design dictates how we'll build the architecture in the longer term. This is going to save the Program millions in the long run.
[Our Lead Architect] supports this approach. I'm happy to set up a quick conversation with him so that we're all aligned."
They agreed to invest in a 3 week Discovery Sprint.
Determine scope
After interviewing a senior ops team member to understand the foundational aspects of ops - systems, team structure, KPIs, pain points, jobs-to-be-done - I worked with the Product Owner and Business Analyst to decide which systems to focus on for a 3 week Discovery sprint - we couldn’t get across all six systems in-depth within the timebox.
We chose eOCP and ITF because they were:
A) the most used systems, and
B) Because one had the least amount of dependencies on other systems, which increased the chances of shipping a release sooner.
We chose eOCP and ITF because they were:
A) the most used systems, and
B) Because one had the least amount of dependencies on other systems, which increased the chances of shipping a release sooner.
AI design workflow
Problem solving how to revise my first sell-in pitch
Consult Claude AI after I understood why Product didn’t want to initially invest in the Discovery process. Compared to other AI’s, one of Claude’s strengths is providing advice for situations that require emotional nuance.
Consult Claude AI after I understood why Product didn’t want to initially invest in the Discovery process. Compared to other AI’s, one of Claude’s strengths is providing advice for situations that require emotional nuance.
AI-assisted workflow
Problem solving how to revise my first sell-in pitch
Consult Claude AI after I understood why Product didn’t want to initially invest in the Discovery process. Compared to other AI’s, one of Claude’s strengths is providing advice for situations that require emotional nuance.
Consult Claude AI after I understood why Product didn’t want to initially invest in the Discovery process. Compared to other AI’s, one of Claude’s strengths is providing advice for situations that require emotional nuance.
Review current state
I reviewed system documentation and paired with our Business Analysts to download as much info as possible. They’d had a strategic head start in context building.
Example insight:
Example insight:
A key scenario where ops need to initiate a payment:
The FX markets are closing for the day, and the customer needs to make a high value or crucial payment (e.g. to honour a contract)
via a system that doesn’t permit straight through processing.
Ontology mapping
Ops speak and operate in a whole other language and world.
Example:
Example:
“So using PACs terms, for Day 2 payments we can add the full range of instructing or instructed agents in ITF the way we could if keying a message manually for MT104 and 103s.”
- Senior Analyst, International Payments
By systematising the complexity, I could better articulate how to connect the different aspects of the customer experience together AND provide foundational knowledge for how we might phase the approach with the Product Owner.
AI-assisted workflow
Ontology mapping using training material
If there was significant, centralised ops team member training material (e.g. wikis, user manuals for key systems, system error reports), I could ask ChatGPT(Plus) to generate a first-draft ontology map.
The aim would be to define domain-specific jargon in simple terms, map how it all relates to each other, quality check it with an experienced team member then disseminate within the squad to speed up with consistent context building.
If there was significant, centralised ops team member training material (e.g. wikis, user manuals for key systems, system error reports), I could ask ChatGPT(Plus) to generate a first-draft ontology map.
The aim would be to define domain-specific jargon in simple terms, map how it all relates to each other, quality check it with an experienced team member then disseminate within the squad to speed up with consistent context building.
Async pain points exercise
I sent out an sync task above to inform the current state customer value map, and would answer any knowledge gaps during stakeholder interviews.
Stakeholder interviews
I interviewed the ops Heads Ofs, execs, retail and backend individual contributors. For senior leadership stakeholders I focussed on KPIs, $$$s and the wider market. For individual contributors, I focussed on jobs-to-be-done, learning ops concepts and questions from the pain points exercise that needed further clarification.
Example insight:
Example insight:
“We had a $(5-figure) loss in one day from one generic non-validation issue.”
Image created using Midjourney AI.
Consult analytics
I requested everything from average time to complete key tasks, customer segments, volume and $ value of payments on the different ops systems to:
A) Gain a baseline for the current state customer experience, and
B) Inform the business case with numbers around $ loss risk for each platform.
A) Gain a baseline for the current state customer experience, and
B) Inform the business case with numbers around $ loss risk for each platform.
Concept and recommendations
The stakeholder feedback was that we needed to quantify the impact of some of the pain points:
e.g. What’s the time / cost associated with the workflow disruption pain points if any?
Given the short timebox, we needed to explore this in detail.
e.g. What’s the time / cost associated with the workflow disruption pain points if any?
Given the short timebox, we needed to explore this in detail.
AI-assisted workflow
First-draft research synthesis
So far, ChatGPT has produced mid-weight researcher level insights. They’re still quite generic so require user oversight and time to extract nuance. Kraftful is great for saving time to summarise pain points and but not yet capable of writing free-form insights.
So far, ChatGPT has produced mid-weight researcher level insights. They’re still quite generic so require user oversight and time to extract nuance. Kraftful is great for saving time to summarise pain points and but not yet capable of writing free-form insights.
Outcomes
Program-level
• A clear cost out number was articulated to rationalise a higher $ value business case for the International Ops uses cases in the future. This figure had never been articulated before, leading to under-investment in fixing the ops experience and the continued fragmentation of ops workflows.
• I shifted our working group towards product-focussed outcomes e.g. which systems contributed the most to payment failures / had the highest usage – instead of just a blind re-platform of everything.
• I shifted our working group towards product-focussed outcomes e.g. which systems contributed the most to payment failures / had the highest usage – instead of just a blind re-platform of everything.
Project-level
• Two key ops systems were strategically sliced into smaller phases, providing speedier value to market.
• Pain points and dependencies were highlighted, which provided stakeholders with a view of HOW to strategically re-platform instead of wasting their project budget on a single big bang release that never gets shipped.
• Pain points and dependencies were highlighted, which provided stakeholders with a view of HOW to strategically re-platform instead of wasting their project budget on a single big bang release that never gets shipped.