Debit card point API for financial institutions

TL;DR

Built an API that would give point collecting capabilities to debit cards issued by small to mid-sized financial institutions (i.e. credit unions and regional banks). Even though there was strong interest from two potential MVP candidates, the technical complexities around integrating with antiquated on-prem systems proved too great and I didn't pursue this project to the implementation phase.

Personal Objective:

I undertook this project to learn about what it takes to build, sell and ultimately integrate B2B enterprise software for financial institutions. I spent a fair portion of my career analyzing and working within major banks so was already somewhat familiar with the regulatory and technical complexities associated with selling software to them. However, actually doing so would teach me a great deal about just how onerous and challenging this process was for all stakeholders involved.

Problem:

Chase, Citi and Amex are the top 3 largest card issuers in the U.S. by market share. All three place strong emphasis on their point card offerings, which they use to lock customers into their respective financial ecosystems. Chase and Citi, which are key parts of massive multinational financial service conglomerates, are able to upsell their customers to high value products such as home mortgages. Although most small to mid-sized financial institutions issue their own debit cards, the majority don't bother with point systems due to the complexity and resources involved with building such products internally. As a result, they lose a potentially strong ecosystem enhancer that could better lock-in customers and make it easier to upsell their customers to high value products such as home mortgage loans down the line.

Solution:

An API would enable financial institutions to add point capabilities to their existing debit card products. Such a product would ingest transaction data via the Visa and Mastercard APIs and integrate with existing financial institution systems (on-prem or cloud-based architecture).

Process:

I started off by speaking to numerous individuals that had worked for the credit card divisions of major banks in order to assess how internal systems were structured and what growth strategies were employed to build point programs over time. One interesting takeaway from these conversations was that even in recent years there has been little effort made to build a concerted strategy around actively upselling credit card customers to higher value products based on actual card activity. This was in large part due to relatively limited collaboration between the teams in massive organizations that could enable this.

I worked with an engineer to map out the API and identify how it would ingest data from debit cards via Visa and Mastercard APIs, tag relevant customer transactions with points from participating retailers (i.e. Starbucks, etc.) and interface with bank systems. APIs were scoped for both banks that still maintained on-prem systems and those which have migrated to cloud systems.

I was able to get in front of decision makers within two regional banks in order to assess product-market fit and determine how to best integrate an MVP with bank systems. I also spoke with B2B startup founders that had successfully sold their software products to banks in order to map out a more effective path forward. Though these conversations were illuminating, the subsequent technical challenges of how to successfully integrate the API with bank systems became readily clear (i.e. COBOL code running on IBM mainframes).

Outcome:

Judging from my conversations with bank software decision makers, there appeared to be a strong product-market fit for the API. However, given the onerous technical complexities involved with actually integrating the API with the on-prem systems of the banks targeted for testing the MVP, I decided to deprecate the project. Most financial institutions that still utilize on-prem architecture have some plan to migrate to the cloud in the future and going forward with a 3-4 year build cycle only to release a redundant product seemed too large of a risk to take.

Post-Mortem:

If I did this project again, I would:

A) Look to embed our engineering efforts with a bank partner from Day 1 to get a proof of concept up and running as soon as possible.

B) Once the MVP was up and running with the first customer, I would look to identify common build components and those that needed to be customized for each customer financial institution in order to develop efficient sales and integration roadmaps that could be used for winning over subsequent customers. I would also group financial institutions by internal software architectures in order to identify and specifically target the most promising early customers.