SPEI: the engine that processes all the wire transfers in Mexico, the only and almighty one.

Since the beginning of times using SPEI to do payments between different banks has been an awful experience, some hard numbers that showed up in the benchmark:

TIME IT TOOK TO DO A SINGLE PAYMENT (less is better)

1) BANORTE: Mainly because of the “need” to register the bank account (a process which took 30 minutes to update). All the other banks got rid, somehow, of this “feature” at least one year ago.

2) BBVA: The main issue was copying manually de CLABE number between apps because, at least in iOS, there wasn’t a way to copy/pasting it, incredible right? It was an input without the basic attributes of an input. Like when an input to write down 6 numbers appears but the keyboard popping up is a regular QWERTY one instead a number pad.

This benchmark was done somewhere half of 2019, hopefully the average time had changed.

I was looking to improve the payment experience to outstand from all the competition and become a facilitator of a very difficult process (well, if you have to pay it is always difficult to say goodbye to your well earned cash).

The main reason of these improvement was to become a differentiator with the most used feature.

We expected the user to be quite comfortable with the payment process and become the number one alternative vs. other major banks (yes, the ones mentioned before in the benchmark).

But wait: how are we going to become the number one payment possibility if the users had plenty other banks? Well, that was easy taking advantage of one of the mains features of Swap: being a wallet.

When this improvement started I was working as a Product Manager + Product Designer (yeah, it was a lot of work but I wanted to taste the beautyness of both worlds). It was a solo adventure; I was the only designer involved).

I worked alongside the main stakeholders, these being: marketing (also a combination between marketing and data analyst), the CEO and the developers (the all mighty techie guys as we call them), the client support manager and also once in a while a chat with legal was necessary as there are always doubts about what you can and can’t say in this well regulated industry (I mention this last one because plenty of fintechs had been fined with good amounts of money: up to $9M MXN) just because one single word was used wrongly, so extra precaution has been implemented since then.

The first approach I took was having a meet with my number’s master (which is my marketing/data science manager) to review the funnel and get some general insights about the process.

The manager of the Support team was key as they have a top 10 most received issues, plenty of them were related, directly or indirectly, with payments.

Also it was the opportunity to review my good ol’ improvements annotations notebook. This one contains several improvements talked here and there with random meets, chats, emails, thoughts, workshops, etc. with every member of the team since I started at Swap.

Next step was doing some field tests with heavy Swap users to obtain ‘real world’ insights.

Discoveries:

How we were going to measure success?

Definition	Metric
1. Successful Payments	Number of drop outs
2. Failed payments	Number of failed payments
3. Support contact regarding payments issues	Less payments topics
4. Saved payment receiver vs. new transactions (from scratch)	TXs comparision
5. Shortcuts payments vs. New Payments	TXs comparision

The main reasons payments failed were:

1. SPEI failure: Random dead times causing delays in transactions.
2. Transaction limit reach (defined by the level of the user).
3. The origin of the funds (credit or debit card) were rejected by their banks (mostly because of not using a digital card for a digital transaction).

As the project got more complex, we had the need to redefine what we wanted to accomplish:

This is how:

1. Whenever a user entered Swap we announced a possible delay because of one of our providers (SPEI), not only blaming them but making clear what where going to happen with their payments, assuming the responsibility.
2. About the user limits why had 2 quite different solutions:
1. Implementing a way to validate each of our transactions.
2. Separating the transactions in two different types, depending on the origin of the funds: balance and credit/debit cards. So we let the user able to move any amount of money directly from their balance (this also helped the business as we saved tons of money in transaction fees).
3. Implement a dynamic CVV interface to let the user write it in (this solution brought to life new problems like why a user would open its bank app everytime they did a payment, but for now it was enough. This is a good example of versioning and how a solution kept the need of being assessed and got a fancy place in the backlog).

The original user journey for a payment was:

*There wasn't a way to create frequent contacts (although it was the 2nd more frequent transaction type, only behind new transaction).

The proposed journey merged both worlds: new transaction and new frequent contact.

Contextually:

– 95% of the time a user had the need to add a frequent user were in the flow of creating a new payment for this same user.

The journey evolved to:

Results:

The total number of steps decreased by 40% but time, the real metric here, was reduced by 45%.

Swap aginst the #1 bank in Mexico:

These were all the improvements: