A better bank: what it takes
This final piece in the series is now to bring everything we’ve explored so far together and to apply them to answering the question:
“Can we actually start a better bank in T&T right now?”
In our last article we took a look at the Visa stack and the business of issuing prepaid debit cards as one route to bootstrapping a digital banking experience.
In this piece we will now explore the business and logistics of a USD-based Visa Prepaid Card Program within a T&T context. Remember, the aim of this is to create a digital experience first, and the card program is simply a proxy for our internal systems to interface with the outside world for users.
When evaluating a program like this, I would generally think of two broad categories of things:
- How do I design a UX around this for a TTD-based audience?
- What are the potential risks to the successful functioning of this program?
Considering the UX
UX or “user experience” refers to how the user is guided through using your application, and how easy or difficult this is for them. Good UX usually means more active users and more deep usage of your app, and bad UX can mean poor adoption and eventual failure of the entire service.
The importance of UX means that we would have to be very deliberate when thinking through how a user interacts with our service and how they are guided through different bits of functionality. We would have to be especially mindful of the elements that can come across as painful or even non-starters for users. These likely pain points would need to be addressed, and if they can’t be, it usually means that the initial strategy should be tweaked or reconsidered entirely to ensure the best chances of success for our new service.
Given this context, the following is a layout of some of the key UX points for our users. For each point we consider how easy or not it is to implement and maintain as a piece of functionality within our app.
Features & Functionalities
For this service, I would like my users to be able to:
- 📝 easily sign-up
- 💰 carry a TTD balance
- 🤝 send/receive with contacts in the app
- 💳 pay merchants using their card both in-person and online
- 🤑 top up their account from their existing bank account or other TTD-based sources (like their salary)
- 💸 withdraw funds from their account either to other local banks or as cash via an ATM
For each of these pieces of functionality, a ✅ indicates that the feature should be implementable, a ⚠️ means the feature is possible but not ideal, and a ❌ means that the feature will likely be problematic.
⚠️ → 📝Easy Signup
Unlike with traditional apps, signup will likely involve some KYC steps. This product would be one offered under license of some sort of financial institution, and these institutions usually require certain pieces of information from users to maintain compliance with their regulators.
In the past, this has been especially problematic for T&T citizens trying to use services abroad since we’ve had a rough standing with satisfying AML/CFT requirements at an international level (more here on our FATF greylisting issue). While this is currently improving now, it’s still an important consideration to keep in mind.
Terms:
- KYC — Know Your Customer
- AML — Anti Money Laundering
- CFT — Countering the Financing of Terrorism
✅ → 💰 TTD Balances
Having a USD-denominated card would mean that balances would likely be carried in USD. This shouldn’t be a problem though since it’s fairly trivial to show a converted version of this balance in TTD, and the relatively stable USD/TTD rate means that it shouldn’t fluctuate so much as to confuse users.
There are likely also schemes we can potentially use together with an E-Money Issuer license to create a synthetic TTD token for the purposes of usage within the app alone, to more accurately create a TTD balance while maintaining USD interoperability.
✅ → 🤝 Send/Receive In-app
This is fairly straightforward to implement in one of two ways.
The first option is to lean on the “Visa Card” as an account and to use their “Visa Direct” functionality to move funds between users.
If this becomes problematic or too expensive though, as a second option we can also implement an internal accounting layer together with some netting mechanism to manage this.
✅ → 💳 Making Payments
This is very straightforward since funds are:
- already in USD, and
- already have access to the Visa network
❌ → 🤑 Loading money in
Getting money from TTD to this system could prove problematic since it involves being able to access currently scarce forex in T&T.
There are two options for loading money into the card. The first is via credit card transactions from an existing TTD-denominated card with a USD quota on it. Top-ups can be done as with any normal card transaction, but the problem would be whether persons would want to use their scarce USD quotas for this. A 2nd potential issue could be banks choosing to outright not even allow credit card transactions to our service on a purely discretionary basis. Local banks have shown a tendency to do this with things like blocking transactions to cryptocurrency exchanges in the past.
The second option is to facilitate persons being able to load in via a bank transfer to a TTD account held by us where we would facilitate the conversion to USD and transfer into our service. This is again problematic given the extremely scarce availability of forex for exchange like this currently throughout all the banks.
⚠️ → 💸 Taking money out
Even after loading money in, getting it back out as a withdrawal into TTD could also be problematic.
Again there are two potential options for this, neither ideal. The first is to lean on the ATM network to withdraw cash at physical machines. This would likely carry fees that can be managed, so it isn’t a huge problem.
The second option would be to have folks do a USD transfer (likely via Visa Direct or something similar again) to an account we hold and for us to handle the hop back to TTD as eventual deposits to bank accounts.
With both of these options though, there is the issue that the bank’s buy rate for USD will likely be lower than consumers would prefer, with users taking an additional 3% hit for example in exchange fees in addition to any other fees.
These withdrawal problems are altogether not necessarily a feature killer, but they do add external complexity and could potentially affect the economic viability of the program as fees start to add up that aren’t in line with the expected experience from users.
Overall Feasibility
Pulling apart and exploring each of the components of our user experience above now gives us a great base to make an assessment on how we might move forward with implementing this service. Interestingly we did uncover some points that could be potentially problematic, and these should be considered before we move forward any further.
The potential issues from the above functionality analysis seem to be around:
- being able to onboard and keep users
- withdrawing funds
- loading funds in
Onboarding
On the onboarding point, the FATF greylisting was a point of concern, but things seem to be moving in an acceptable direction now.
Can we work around this? -> ✅
Withdrawing
Also, withdrawing funds appears to be potentially problematic, but by itself it probably isn’t a product killer.
Can we work around this? -> ✅
Loading Funds In
The issue of being able to easily load funds into the system is a serious point of concern though. It will take some time before this service can stand on its own with circular activity within it, and until then users will absolutely need to be able to freely move into and out of it if they are to confidently be able to use it. The forex interchangeability issues are concerning because the situation seems to be worsening rather than improving, and the ability to easily load funds into the system is a critical feature of the system being able to work effectively.
Analysis pieces like this one by economist Marla Dukheran paint a less-than-ideal picture for our near-term economic outlook and the impact of this outlook on our foreign exchange levels. We are also already seeing local businesses run into significant problems with being able to access forex to pay suppliers and conduct their normal business activities.
Can we work around this? -> ❌
In this case it’s starting to look like we’re stuck because I can’t see a viable way to cross our TTD/USD divide.
Getting unstuck: a TTD-based alternative?
Given the above analysis it seems that for a USD-denominated Prepaid Card program, while initially it is an attractive idea for bootstrapping a local challenger bank, in practice it would be much more difficult to implement and maintain at scale.
Considering though that initially all we were looking for out of a card program was a link to the outside world, what about the idea of sticking to a TTD-based program? Could this approach be a viable one given that we have now decided that a USD-denominated program could be highly problematic?
As explained in the Layered Money post, TTD-based Visa cards work similarly to our local Linx card except that they rely on the Visa network for sending payment messages around. Their settlement remains as TT Dollars, and so you are limited to shopping at TTD-accepting merchants only, both online and in-person.
Does it work for our planned UX?
When looking at the points under our UX and reapplying them to a TTD-based program, the key considerations that would change are:
- 📝 Easy sign-up
- 💳 Paying merchants
- 🤑 Topping up
- 💸 Withdrawing
Sign-up, withdrawing & loading in
The easy sign-up, topping up and withdrawing feasibility improves significantly under a TTD-only approach since we are now squarely within the T&T ecosystem and have much fewer restrictions to consider.
Can it work? -> ✅
Paying Merchants
The paying merchants functionality now becomes a huge issue though for exactly the same reasons. Being limited to the T&T ecosystem means that we likely won’t be able to make any purchases to online service providers, online merchants and any local merchants that process their card transactions outside of T&T. This is firstly a problem given how much of our local retail happens on international marketplaces like Amazon, to be eventually fulfilled via some skybox service.
This is also a significant consideration because more local merchants are starting to process card payments outside of the country as a workaround for them to access foreign exchange for their own businesses. This means that even seemingly “local” transactions are becoming international transactions as well, that a TTD-only card can’t support.
As a final consideration, it also means that the cards and system would be useless to folks who are traveling outside of T&T.
Can it work? -> ❌
Does it work for our broader strategy?
On evaluating the feasibility of our original plans under a TTD-only strategy, I can see of a number of potential problems when thinking through both the implementation and the outlook for my original idea.
Utility
As explained above, being TTD-only removes a large section of potential merchants and services that users will be able to interact with. Given how dependent we are on services and marketplaces outside of T&T, this could potentially be a significant problem for any new payments upstart.
Total Addressable Market (TAM)
As described in the first post of this series, part of the original vision was to eventually move to other Caribbean territories. With a USD-based approach this is easy, but by limiting our system to little walled gardens restricted by local currencies this makes interconnection much more complicated. The alternative of just focusing on singular territories is also problematic because of the small relative populations in any given territory.
Competitive environment
T&T has recently also seen a flurry of activity around providing payments and fintech solutions. Limiting the pool of services and merchants we can interoperate with puts us in direct competition with some other planned ventures we know of, with very little room for product differentiation.
Financial Infrastructure Access
Falling back to TTD likely means we’d need to partner closely with a local bank, whereas before this was less necessary. The local scene so far has been one where banks have shown unwillingness to expand past traditional business models, and they generally appear to be apprehensive to working with fintechs and adopting digital solutions.
This can be evidenced with the fact that our local Linx network is mostly still analog-only from a user’s perspective, and that trying to accept a digital payment locally today in 2021 is still a massive pain when compared to more developed financial ecosystems. This was covered in the first post of this series.
Given these, trying to get access to our local infrastructure will likely be no easy task. It will likely involve significant work in making a case for the service and scoping out potential arrangements with banks, and then some legwork in implementing the technical bridges to enable such a service. These are probably outside the scope of the initial strategy for this idea, but could fall within scope for any persons looking to implement open banking solutions for our local ecosystem (LatAm example).
Limited regulation
There is very little room to work around partnering with local banks given the current state of our regulations. While other jurisdictions have provisions via an array of licensing options and regulations for fintechs to operate, our local regulations are still being actively developed and likely won’t be ready for some time.
So far we have gotten a new E-Money Issuer license which is positive, and there is a Payments System Bill currently being actively worked on. Depending on how things play out in the near future, this means that this particular criticism of lack of regulation will likely be less of a concern.
Potential Pivots
With all the considerations outlined so far, it does look like the original idea for getting a challenger bank going locally via a USD-denominated Prepaid Card program has a few hurdles to overcome before it can be a viable approach. This means that this particular idea of mine will now have to be shelved in its current iteration.
This does not mean that the idea stops though, but rather that the problem must now be redefined. With the major issue being foreign exchange access and liquidity, it looks like any future solution could focus on this point as a point of leverage to start working around.
As explained in the Layered Money post, “forex” itself can be considered a part of our financial infrastructure, and the unique challenge of figuring out how to build a solution that can work around this “bridging” element could be key to coming up with a successful next iteration to work on.
My Personal Take
This series wasn’t so a much a “how we build it” series as it was an explainer of where I’ve gotten to and why I’m stuck. The intention was to lay out as clearly as I can all the steps I’ve taken so far and the reasoning behind my final conclusions at this point. It was also intended to help add to our national conversation around what the context is for better banking and what some of the nuts and bolts are for builders who are already on this path or just getting started.
At a personal level, I’ve refocused my efforts on exploring some of the new ideas floating around about international settlement and alternative approaches to core banking. I’ve recently taken up a technical role with a company that’s working on the problem of building bitcoin-enabled core banking software in El Salvador within the context of that country declaring Bitcoin as legal tender there. The company has chosen to architect its solutions in an open-source way, and has been engaging the wider software developer community in interesting ways around its initiatives. It has also been drawing attention from communities and institutions in other Latin American and developing nations that have been exploring some of these possibilities.
El Salvador specifically will be an interesting starter country since its government has chosen to engage in the ambitious exercise of building an alternative national digital payments system based on the platform of digitally native virtual assets. I expect that whichever way these initiatives go, there will be some useful lessons that we can apply to the Caribbean context from this.
I’m also excited about other ventures that have recently been popping up locally to tackle some of the same issues I’ve talked about in this series. My friends at Zed Labs for example have been working on a blockchain-based mobile payment system called Wam that has some ambitious plans for rolling out digital payments to merchants and everyday folks locally. Their instagram profile has some story highlights by Mark sharing some of their journey so far in putting things together.
I’m optimistic that given all these things, we should soon be able to crack the problem of seamless digital payments in the Caribbean. Cracking this means enabling more easy access to the burgeoning digital global economy for our own Caribbean people here at home, which I think we can all agree is something we need to get sorted out sooner rather than later.
- (Part 1) Can we start a better bank in T&T?
- (Part 2) Layered Money
- (Part 3) The Visa Stack
- 👉🏽 (Part 4) A better bank: what it takes
