Open APIs took open banking and banking as a service (BaaS) mainstream by allowing secure and efficient connections between banks and fintech companies or other third parties. As newcomers provided disruptive financial technology and incumbents provided longstanding financial expertise, much of the early talk of head-to-head competition shifted instead to talk of partnership-based competitiveness.
A classic case of BaaS is BIN sponsorship, which refers to a licensed “sponsor” bank letting partners use its bank identification number (BIN) to conduct card issuing and acceptance activities. The exact nature of the sponsorship involves careful consideration by both parties.
Unlike co-branded partnerships, where banks handle almost all aspects of a card program outside of some marketing and customer acquisition, a white-label BIN sponsorship puts more focus on the recipients, often smaller fintech companies, who can then self-brand their programs.
A sponsor bank might share capabilities, including licenses, without any scale requirements or major investment commitments. Settlement, fraud management, and regulatory and payment network compliance should suffice. A fintech recipient might handle everything else: marketing and customer acquisition, customer onboarding and fulfilment, transaction processing, customer service, and back-office requirements.
Specific approaches are dictated by need and usage. A BNPL provider wanting to open its “closed loop” retailer network to an “open loop” payment network may want to issue pre-paid cards. A neobank or challenger bank wanting to take deposits yet unable to hold the funds may want to issue debit cards. An alternative lender adept at non-traditional credit scoring may want to issue credit cards with defined spending limits.
Both sides will also want to closely watch the evolving nature of their partnership. A growing fintech may want to pursue licensing of its own if it ends up sharing too much revenue with its sponsor bank. Meanwhile, sponsors may not want to retreat too much into the background while recipients build up their own customer-facing brands. At the same time, third-party risk management (TPRM) poses security questions as breaches are liable to extend across partnerships.