Ron made a bold claim in Banking Rebundled over at The Financial Brand.
Today’s banks will become the “attractors” of the future – firms that RE-bundle the emerging set of banking services, providing the front-end interface and back-end integration.
He leaves a critical question hanging out there:
How is this all going to come together for any one customer?
If you have any responsibility for driving tech at your credit union, do this first: Read Bruce Cahan’s Filene paper “Choosing Relevance: How Credit Unions Can Harness Transparency and Show Impact”. Despite the title, it’s a technology paper. If you doubt you’ll get anything from it, start with the list of collaborators in the preface. If you’re already thinking TLDR, then just skip to Chapter Four and the discussion on Core-Tech and User-Tech. It’s foundational for what we’re about to break down here.
Credit unions face a daunting challenge.
You know you need to move faster; deep down you know today’s “happy” members are going to turn angry at the ridiculousness of it taking days and days to move money into and out of their own accounts with us when they can tap a button and complete complex transactions with on-demand drivers picking them up based on their location.
You know your members have a right to be impatient about how long it takes a loan from application to funding; it doesn’t help that we can’t give them a simple update on its progress when they can track real-world items moving from warehouses to their front doors.
You’ve heard pundits for years calling for your services to be integrated across your channels (I even had that in my job title once upon a time); yet we still default our processes to tell the member to “call between the hours of 9 and 5 to complete your transaction.”
You know you need your systems to talk to each other and that many are doing this through enterprise APIs; but when you Visio-diagram-out the systems on your back-end, you wring your hands because vendor A competes against vendor B and there’s no way they’d ever make friendly and have their systems talk to each other.
Yes, you deal with real money. Safety and security are at the foundation of your responsibility to your members, and they should be. And it has become a convenient excuse.
Regrettably, credit unions routinely sacrifice innovation on the altar of caution. It’s time to stop.
A few days after the question above was posed by Ron, David Gerbino tweeted:
Matt’s response, in a series of tweets:
Back to Ron’s question: how do you do it?
Get started on that enterprise API so that you can separate your Core-Tech from your User-Tech. Trust those vendors on the Core-Tech side to do what they do best: automating loan decisions, sending out bill payments on your behalf, keeping the “paper” documents in compliance, acting as your ledger, and on and on. But for Pete Drucker’s sake, realize that your user-tech - the interfaces on an ever-changing variety of devices - must be now held to a bar that Amazon, Facebook, Uber, Pinterest, and MX set and continue to raise higher and higher.
These thoughts come from a lot of conversations between Matt, me, and some big bright minds in the space. Matt’s built it from the vendor side, I’ve led a team doing it from the FI side, and many of you have already gone down the road as well. You call it an ESB, a middleware layer, an enterprise API, etc…. Build that thing out and expose it.
What should the FI should be responsible for? The FI should own integrating the systems and providing “raw” data.
What should the group responsible for the interface (mobile apps, online banking, loan apps, membership apps, etc.) be responsible for? That UX team should own building the member experience on top of that data.
When going this route, strive for an enterprise API that captures every manner in which your members interact with your credit union.
And to be clear, the APIs provided by your core and other technology partners are crucial and should serve as key components in your own enterprise API. Indeed, the quality of a vendor’s API should be a key metric by which that vendor is evaluated. However, if you want to be able to respond to the specific needs of your members – if you want to be able to say “yes” when you want to get an idea to market that your tech vendors aren’t yet on board with – then your enterprise API must be your own, and it must be the primary interface to your credit union.