Setting up a card issuing business line requires collaboration and careful business modeling.

The setup: becoming a Program Manager

To issue cards you need to play in two regulatory spaces - firstly within the central bank’s regulations and secondly within the card scheme regulations. Depending on the country there are different roles which will be played out by each institution. Let’s assume that your company will partner with a bank to launch the card product.

The following entities are relevant:

1. Issuing Bank (aka BIN Sponsor) - this is the bank which is licensed by your Central Bank AND the Card Scheme to issue cards
2. Technology Provider (aka 3rd Party Processor, TPP) - a company which is certified by the Card Scheme to issue cards and to process transactions against those cards
3. Card Scheme (in the west this is likely Visa or MasterCard) - you’ll need to decide which type of card you wish to issue, this may be done in collaboration with your Technology Provider or you may also have a side deal with the Card Scheme directly
4. Program Manager - Yourself! You are responsible for executing the whole end to end service, including product design, customer care, operations and marketing

The Program Manager owns the customer and the other parties generally sit in the background. Of course the card scheme logo still goes on the card!

When a customer makes a purchase on the newly issued card is it routed through the 4 party model (merchant > acquiring bank > card scheme) to your Technology Provider (which is working on behalf of the issuing bank) and funds are taken from the card if the transaction is approved successfully. This partnership is important to operationally support your customers.

Note - Card schemes are unique network businesses and tend to be governed by their rule books. The lawyers at Visa HQ sit on the top floor for a reason :)

Going live: play by the rules

So by this stage you have agreements with your BIN sponsor, a Technology Provider and perhaps a Card Scheme. You’ve done your integration and designed the product UX. You’re ready to go, right?

Well, nearly…here are some extra things to think about:

1. Customer tariff - how does your business model reflect within the tariff set for the customer and how will you communicate this effectively?
2. Operational processes - have your trained your team on the relevant processes? These will mostly be financial but may also include compliance aspects.
3. Settlement to Visa - have you pre-funded your settlement account at your BIN sponsor ready for customer spending?
4. Commercial settlements to your partners - how does revenue reporting work within your commercial agreements?
5. Data management - how will you get data from your Technology Provider to run customer analytics and the relevant customer promotions?

The operation of the card product is governed by the Card Scheme rules. They control the settlement cycle and will charge their fees pre-settlement. You’ll receive monthly invoices from the BIN Sponsor which explain the fee structures. Be careful that you understand the fees, there is some complexity here!

Pricing, pricing, pricing

And to the heart of the product - does it make money?!

You might get revenue from the following sources:

• Customer fees (transactional or periodic)
• Share of interchange
• Share of FX on international spending

You might have costs from the following sources:

• Transaction processing from your Technology Provider
• Transaction processing from the Card Scheme
• Costs around liability shifts (for example, the OTP SMS and processing from Cardinal Commerce or similar)
• Commercial arrangement with the BIN Sponsor
• Commercial arrangement with Technology Provider

Domestic and international transactions will have different cost/revenue profiles, with the FX making international transactions more profitable. However, they will also have higher costs from the Card Scheme as they claim more value for the more complex routing. As you plan the business model - make sure that ALL fees from the Card Scheme are known (including payments for declined transactions!). Personally feels like card scheme pricing models have become more and more ‘optimised’ (i.e. horribly confusing) overtime. Your BIN sponsor should inform you of any changes.

Many of these transnational fees will need to be offset with customer fees. BUT, as you’ll want to keep your fee structure simple, some fees might have to be covered by general pricing. Depending on your market some fees may also be limited by regulation. We’ve European FinTechs work towards subscription models by bundling many services together to cover their costs. This is a good route towards profitability. Adding segmentmentation on top (hello Revolut Metal card) is also a good strategy.

BUT cards are a commodity

As card payments are useful to customers, we’ve seen many FinTechs provide virtual and/or physical cards to customers, but the core ‘spending’ feature is a commodity.

As you launch the service, you’ll need to understand what additional value you’ll be providing to customers. These value adds will differentiate your service from others and ensure adoption with your customer base. Other companies have each taken a different path around some common themes including security, transparency, promotions, credit provision and spending management or a mix of all of them.

Checkout the Apple Card launch in the US from 2019 for a wonderful play book of how to do this successfully. Apple gave customers a cashback offer and tied the card strongly into the ApplePay channel. Among other things, later they extended interest free offers for the purchase of Apple goods. Buy your iPhone from Apple with Apple anyone?

As you think through these additional services you may want to reflect on your original business model for the core spending aspects, it may enable or disable certain paths depending on how you have configured it. Now might be a good time to address your assumptions given your future plans.

Summary

Many companies have become Program Managers and launched physical or virtual cards. If you are planning on doing the same, I suggest you to go in with your eyes open!

Like with everything, make sure to know what value you can provide and do your homework 😊

Good luck!

Introduction

Two weeks ago, a small team of adventurers from PalmPay joined the Mojaloop hackathon which was organised by DSF Labs on behalf of the Gates Foundation. Wow, that sentence needs explaining! Let’s get some background.

The Gates Foundation and others believe that one part of the financial inclusion problem is due to the limits of existing payments infrastructure. With an aim to improve inclusion they started an open-source project called Mojaloop in 1997. The platform aims to reduce payment costs, build bridges between existing systems and create new experiences for customers. Moja means ‘one’ in Swahili – one loop for everyone.

Mojaloop is a payment switch which is available to anyone and can be used for P2P transfers, account management and general disbursements. The software is supported by the Mojaloop Foundation with a team of technical experts who continue to build depth into the platform. We wanted to explore how it could be relevant to PalmPay in our existing and new markets.

Starting bright and early on Wednesday, we installed Discord, and got ready for 3 busy days of learning, talking and hacking. Some well known names joined us including Chipper Cash, Abeg and OnePipe.

The Problem

Conversation and socializing has always been a big part of commerce in Africa & other emerging markets. It’s how potential customers engage merchants, get the best deals and assess the quality of the merchant. Over the years, companies have tried to implement payment bots to digitalise these flows. Previously this has come with some challenges including implementation costs, high transaction fees and limited payment options.

However, this market dynamic is changing as WhatsApp and other social media platforms improve their e-commerce offerings. Perhaps you’ve started seeing WhatsApp for Business in real life as you interact with small merchants?

If you can review a catalogue of products within WhatsApp, then the merchant is using the business version of the app. However, currently there is no embedded payment flow in the African markets to complete the sale. Our idea was to try to close the loop and build out a “Conversational Commerce” experience. This would help customers make payments over their favourite messaging app.

Our Approach

To create our ideal experience we explored how to link the WhatsApp for Business API to Mojaloop via a bot which would help guide the customer through their purchase. Overall, the flow would be something like this:

To make it happen we need APIs and logic for the following steps:

1. Customer conversation
2. Look up merchant payment details
3. Receive and process the payment
4. Communicate the payment result

The flow is split into two parts – communication (steps 1 and 4) and payments (steps 2 and 3).

Communication

• Mock the WhatsApp for Business APIs to send and receive messages
• Open a sandbox account at Twilio = POST api.twilio.com/Accounts/SID/Messages

Payments

• Use the Mojaloop APIs to:

  • Look up the merchant
  • Initiate a transfer

• Use the demo Mojaloop platform, tech docs here.

  • GET beta.moja-lab.live/parties
  • POST beta.moja-lab.live/quotes
  • POST beta.moja-lab.live/transfer

What we built

We enjoyed the relevance of this idea when WhatsApp changed their user T&Cs on Thursday to facilitate this exact flow within their own platform. They have to share data with Facebook when the WhatsApp for Business APIs is hosted by Facebook on behalf of the merchant. As you might have seen, they experienced some critical customer feedback, but that’s a blog post for another day!

The hackathon took a Design Sprint approach allowing the team to explore and challenge our ideas before creating a prototype. We used the thinking time early in the Sprint to research, focus on the problem area and explore different ways of making the experience real.

The testing platform was extremely helpful to get the API calls working correct – a huge thanks to Stephen from Mojaloop for the support here🙏. If you look closely you can see an account look-up and payment being made here (read from the bottom and go up):

Adding this to our WhatsApp experience we end up with an end to end flow to sell a tennis ball to a customer:

We started thinking about how to tie together the mocked up front end directly to the APIs using Retool, but didn’t finish before the demo in the evening. It was always our aim to do the backend work first and get the solution design correct, so we weren’t surprised to run out of time! If you want to explore more no code platforms here are some additional thoughts.

With thanks!

Hackathons are hard but enjoyable. You start with many “unknown unknowns” both on your initial idea and with the technology. Unpicking the threads and finding your way, as a team, takes perseverance but has rewards as everything comes together.

A huge thank you to the teams at DFS Lab and Mojaloop for running the hackathon and to the Gates Foundation for this hugely exciting project. We enjoyed the loops and learnt a lot!

Know your Standard Operating Procedure

How will you know what to improve if you don’t understand the operational model of your business?

A Standard Operating Procedure (SOP) is a collection of all the processes within your business. This is just a fancy way of saying you know how your business operates.

Encourage each department to make their own process list - ultimately each team is responsible for their own activities. Sometimes this work is driven centrally, but from personal experience it feels more honest to have a decentralised structure. Centrally, you can encourage improvements by challenging individual metrics.

As you scale you may have a set of process documents even use tooling to capture a full model. However, to start, a list of each process with inputs and outcomes will be enough. Using a light weight approach is especially important in start-ups as the business must grow and change quickly.

Don’t burn the toast!

In High Output Management (Andy Grove, 1983) there is a great business process analogy of a cafe making eggs and toast for breakfast. There are multiple layers to such a simple process:

• Which steps are needed for breakfast?
• What order should the steps be in? (Eggs take longer to cook than toast)
• Which steps are critical? (Don’t burn the toast!)

You should try to capture the key activities within each process, writing enough to articulate the important aspects of the process. There are standards for this type of documentation (e.g. BPMN), but try not to go over do it! Things will always change.

Understand your business with metrics

Monitoring the critical parts of your business is essential to respond to change and track your progress. This is done by defining simple and compound metrics to give you an understanding of the business at each level. Clearly different businesses will have different metrics - manufacturing is not the same as FinTech!

Broadly, you should include:

• Customer satisfaction - is the customer happy with the outcome? (Often we use NPS as a proxy here)
• Headline metrics - including revenue, Customer Acquisition Costs, Active Users, Growth
• Output metrics - how many units of work did the business complete? (How many eggs and toast were made?)
• Quality / efficiency metrics - how efficiently did the business take inputs and make outputs? (How quickly did we serve breakfast? Did we spoil any of the eggs or toast?)

Capturing data from a process to generate your metrics may sometimes be challenging (for example, the process may be manual instead of digital). If you cannot measure the metric, reflect on the maturity of that department / process and consider how to enhance your tooling.

Review your shared metrics often

Sharing the metrics and monitoring them with your management team enables everyone to focus with the same level of understanding. Set-up a weekly meeting to review the metrics and reflect on your progress. Feel free to dive into the data beyond the metrics for further insights.

Good Luck!

PS - a16z has some excellent thoughts on start-up metrics

With PalmPay live in Nigeria and Ghana live and 4 more African markets in-flight, here are some lessons from my experience over the last 2 years.

1. Do your research

I know this might appear obvious, but understanding the market landscape before you start gives you the power to make better long term decisions.

Spending time early on to get this right will direct your strategy and give your project plan a strong foundation. Knowing the market will give you a competitive edge - you need to build a unique proposition for your customers to be successful and don’t forget your customers know the market already.

Doing your research means more than just competitive analysis (across features, UX, marketing, pricing). You must understand both the landscape and how different business models work in context. For example, for card payment processing you might want to look at different aggregators, interchange (base costs), layers within the ecosystem (aggregators or direct connections?) and how fraud rates may impact your business.

Lastly don’t underestimate how pricing and promotions underpin your overall proposition. Having a good product is not enough, you must communicate your unique proposition clearly to customers.

2. Plan, plan, plan

So we’re agile, no need for a plan right? Let’s just “assume” it will work…

A plan helps to bring everyone together (insert comment about Gantt charts here). I strongly recommend capturing all the tasks across the entire launch project and map them to your time lines. You don’t want a last minute issue from customer care holding things up just at the wrong point. Pull your team together on weekly calls, moving to daily ones as things get more urgent. Assign someone (or hire) the project manager role and make sure everything is done on time! Talk about your risks and issues often.

3. Go fast or go slow?

Product launches come in many different shapes and sizes - the big bangs, the beta pilots, the waitlists. What will yours be?

In Nigeria, we launched a waitlist where customers could earn some loyalty points by referring other customers into the waitlist. This created demand and we acquired tens of thousands of customers. Using the waitlist we launched slowly by brining customers into the core service. During this period we tested our processes and made improvements. Others have been extremely successful with this approach (see Robinhood for example), but your approach will depend on the product and market.

In general, going slowly can help the business learn and build in quality before you on-board too many customers. Scaling can bring its own challenges.

4. Go step by step

Whatever your launch approach, try to agree the phasing with your business teams so you can move step by step. Define these phases with clear inputs and outputs before you start. This will help give you a context to operate within as part of the project.

For example, the Alpha pilot can start when all stakeholders sign off and UAT is finished (etc etc). The Alpha pilot transitions into the Beta phase when you’ve had X customers and Y transactions, and when the customer feedback has been fully addressed.

Keep your stakeholders close and update them daily.

5. Metrics define success

Your metrics decide how you will measure success - pick carefully! Check out a16z for some great thoughts about metrics.

If you have a data person, get them involved. Otherwise, make your stakeholders responsible for measuring their own metrics and publishing them too! Align on progress daily to start with and then weekly as everything stabilizes.

Good Luck!

With experience managing remote teams over the last 5 years, here are my cheat notes to ensure you remain productive whilst still having harmony.

Build your business rhythm

We are all creatures of habit. Building habits into your team helps with productivity and alignment. Your team will know where to be and what to expect from the important meetings week in and out.

In my product teams, we run morning stand-ups and I believe they can work for everyone irrespective of role.

Currently, we run weekly planning on Monday for an hour and then 15 mins on Wednesday and Friday mornings. Everyone can share their progress, challenges and ask for help. Assign someone to host the meeting (be the Scrum Master) and update the task board - Trello is still a firm favorite here! Our projects and other processes fit into these meeting. Issues are raised and more detailed discussions taken off line.

For the wider processes (Sprint Planning, UAT, release dates), map out the cadences and make sure they are in the diary and keep everyone updated about any changes. For wider dates across the company, shared calendars can be useful.

Build your remote culture, pick your tools and use them

Office culture exists even if there is no office.

People have to work together and they build norms in doing so. As you start your remote team, think about the type of culture you want to create. Your product culture should be aligned with the company, but you may want to push certain values like openness and transparency. Check out the Basecamp employee handbook for inspiration. They are experts.

Tooling is essential to collaborate across geographies and timezones. So much has been written about this, so I won’t go into any detail about it. Select your preferred messaging / video / knowledge management / ticketing platforms and make a start. Make sure that everyone uses them and that new starters are trained about how to use them too.

Get honest feedback with retrospectives

Without seeing each other and ‘lunch room chats’ sometimes process or team issues are not quickly addressed. Use a monthly retrospectives to get everything out in the open and discussed. Creating this time for your team can help with step change where previous processes are not working or don’t exist. It is good to reflect and talk.

If there are many issues to resolve, try to prioritise and focus. There may be only so much you can do before the next retro. Take things step by step.

Mix it up now and again

With your team fully remote, the weeks can sometimes start to blur.

Mix it up with special focus now and again. Perhaps you set aside a week to focus on operational issues or UX. Set the scope of and let the team make progress. At the end of the week you can celebrate your wins!

Try to see each other once in a while

Although, this is difficult (even more so currently), it is worthwhile to see your team in person. Getting to know each other and realise your shared values is helpful especially during times of conflict or change.

If this isn’t possible, try at least to turn on the video once in a while!

Good Luck!

I’ve worked with remote teams across Africa, Europe, America and Asia and have been hiring remote product teams over the last 3 years. Here are is a checklist to help

Know what you want (and write it down)

You are the hiring manager! It is your role to shape the macro and micro aspects of the role.

For example, if you need a new Product Manager:

• Is it a technical, design, operational or a general role?
• What kind of sector experience would you like?
• How senior is the role?
• What kind of background experiences should they have?
• Are there any deal breakers?

The Job Description (JD) must be reasonable - sometimes the “perfect” person doesn’t exist within your budget or may not exist at all! Work with your HR team to improve your thinking before publishing the role. Find inspiration in job listings if you need to.

As you go through the interview process think carefully about the trade offs between different aspects of the role. For example, if you want a generalist PM what is the balance between new product development and strategy or commercial acumen and operational experience. Understanding your preferences will help you select the best candidate.

Source candidates

Use your HR team and personal network to find suitable candidates - the more the better!

Filter and screen

Now that you have a virtual pile of CVs, you need to find the best candidate.

Your approach may change depending on the seniority of the role. Usually my steps are review > telephone screening > homework > 2nd round & approval.

To review the CVs, I follow this process:

1. Review each candidate (CV + cover letter)
2. Decide whether they meet the quality bar of the JD - you’ll find this increases as you review more CVs
3. IF yes, add the a “to interview” folder. IF no, discard
4. Repeat steps 1 and 2 until you end up with 3-6 CVs and then order best to worse
5. Start with 30 minute phone conversations with the top candidates
6. IF candidates pass the phone screening, THEN assign homework. IF not, then pause the conversation with them. You may still come back to them late depending your circumstances

At the end of the process you should have a better understanding of each candidate and understand your preferences. However, you need to validate whether your gut feeling is right. Do this by setting the candidates some homework.

Practically assess skill levels (aka set homework)

By now you should have around 5 good quality candidates for your role.

The simplest way to differentiate is by setting them a homework task. Recently some companies have set very high bars in this area for their candidates with complex tasks or even business development. Avoid this type of abusing of power and focus on the role itself.

Usually I pick an open ended problem which allows the candidate to investigate the processes within the role and share some of their market knowledge. I try to limit the time spent by constraining the slides or word count needed to answer the problem.

If the homework if up to scratch, a final stage interview is completed which includes a conversation about the task and their world view.

By now you should have enough insight to hire the best remote employee for the role.

Close with the best possible offer

Finally, I would recommend putting your best foot forward when making an offer to the candidate (with agreement from HR of course!). You should be confident that your selected candidate can do the job and you want to close them quickly. Remember highly skilled workers may have other offers on the table.

Good Luck!