Role: Liaise with the Integrations Be a Bank team on the CoP feature requirements. Design and test solutions to integrate into the existing Mettle app payment journey.
Why?
1️⃣ Confirmation of Payee is a new way of checking account details to give customers and businesses greater assurance that they are sending payments to the intended recipient, helping avoid misdirected payments being sent to the wrong account as well as offering another important tool to help in the fight against fraud. A payee is the term used to describe the person or business that you are paying money to.
2️⃣ Typically, when a customer or business sets up a new payee or amends an existing payee’s details, Confirmation of Payee will enable them to confirm whether the details they have entered match the account of the person or organisation they are paying.
3️⃣ Putting our customers first, we can offer additional peace of mind that they are paying their intended recipient.
2️⃣ Typically, when a customer or business sets up a new payee or amends an existing payee’s details, Confirmation of Payee will enable them to confirm whether the details they have entered match the account of the person or organisation they are paying.
3️⃣ Putting our customers first, we can offer additional peace of mind that they are paying their intended recipient.
Who? Defining the audience
1️⃣ Customers
2️⃣ Business
3️⃣ Fraudsters
2️⃣ Business
3️⃣ Fraudsters
Focus audience group: Customers
Not gender, age or location specific (age able to use the product) , possible customers with disabilities and accessibility requirements a consideration.
When and where: Understand customer’s context and needs
Given a mobile product for now we should assume this process could happen anywhere, not restricted to a specific office environment.
This could be a process customers choose to do in batches at a specific time, when they have a set amount of time or individually. Should not be restricted to typical business hours as self starters operate on their own time frames. Depending on the business, there might be specific triggers when goods or services are required.
Customers generally take payments seriously. There is a level of concentration to ensure payments are made correctly to to the correct recipient
This could be a process customers choose to do in batches at a specific time, when they have a set amount of time or individually. Should not be restricted to typical business hours as self starters operate on their own time frames. Depending on the business, there might be specific triggers when goods or services are required.
Customers generally take payments seriously. There is a level of concentration to ensure payments are made correctly to to the correct recipient
Customers needs:
CoP is a necessary industry standard process. Depending on the the response received at the point of entering a payee’s details, the customer will react in different ways.
CoP is a necessary industry standard process. Depending on the the response received at the point of entering a payee’s details, the customer will react in different ways.
Value proposition
• Reduce the amount of payee queries Mettle gets as a result of making payments to the wrong account details which could reduce cost to serve
• Reduces the likelihood of customers becoming victim to payment fraud which could reduce cost to serve
• Reduces the likelihood of customers becoming victim to payment fraud which could reduce cost to serve
• Prerequisite for Mettle acting under the NatWest licence
Hypothesis:
Customers want to feel secure and protected against payment fraud, this additional measure will enable customers to feel more confident when making a payment and increase engagement
Outbound CoP will reduce the amount of times customers send funds to incorrect accounts which will reduce the amount of payment queries.
Outbound CoP will reduce the amount of times customers send funds to incorrect accounts which will reduce the amount of payment queries.
Initial user and scenario flow mock ups:
Initial flows and mockups were developed to start wider conversations around the various scenarios we would have to cater for and to determine the ideal journey for a first phase approach to CoP implementation.
Using CoP Operational Guideline and Pay UK documentation as reference we started early discussions with our marketing department to tailor the copy treatment of each scenario message.
Initial user flow mapping
First phase flow mock up and scenario mapping
CoP Phase 1:
The first phase approach included changes to the ‘Add a payee’ view and upon confirmation CoP checks would run in the background and either positive, negative or partial response would be relayed back to the user.
It is important to note that if details were negatively or partially matched a user should still be able to continue to add the payee and make the payment but additional friction should be in place to ensure users are aware that funds could be lost.
First phase indicating positive, negative and various partial match scenario paths.
Tailored messaging is required depending on whether a business or personal payee was selected.
CoP Phase 2 includes an SRD reference field:
The second phase included the introduction of a Secondary Reference Detail (SRD) input field. This was a late edition to the CoP compliancy requirements and was only necessary for certain account types, such as mortgage or utility bill accounts.
This posed an interesting dilemma in terms of what we could provide as a solution as there were various other dependencies that would impact any solution and roll out.
The preferred solution as shown below would allow us to take users down a unique SRD path if, based on the entered account details, we determined that an SRD reference was in fact required for that account type. If this was not the case, users would continue down the standard CoP path.
Earlier solutions included an optional SRD reference field on the Add a payee screen requiring four separate paths.
Thankfully after much discussion we aligned on this approach which would also be a much better user experience for all our users and not just cater for the odd few that might need to input an SRD reference.
Solution to include an SRD reference
This mapping illustrates the less favoured optional input scenario
Wider product and design discussions:
This feature allowed for some fresh eyes on the mobile app product. While creating various mock ups for feedback and testing we were able to have wider discussions around existing patterns, their usage and state of our design system.
Taking the decision to not introduce another pattern at this moment in time, we did agree to work on how we treat internal messaging and make some holistic changes across the product going forward.
Ideation for in app messaging – any introduction would need to consider the holistic view across the application
Mock ups of various radio button selection options. These options prompted wider discussions on existing use case and design system patterns.
How will we measure success?
We will monitor task success rate, task completion time and customer satisfaction.
Future feature opportunities:
As part of this work it became clear that we would have to expand the scope to refine and iterate on other aspects of the Payments journey. As this was not part of our remit our key insights were relayed back to the relevant Payment teams.
Some considerations:
Including a payee reference to help identify payees within the saved payee list.
Icon bank identifier based on sort code entry
Testing showed the scam warning was completely overlooked. Data suggests that there are increasing fraudulent payments being made so forcing users to interact with a dedicated message could be more useful. This would also allow us to specifically address the scam we’re witnessing.
Future opportunities identified during user tests
Prototype
