CHAPTER 5
Application Programming Interface (API)

Why Create an API?

What does digital banking look like in the 2025, and what does it mean to be a true digital bank versus just another bank with an Application Programming Interface (API)? How do banks keep from being disintermediated in this new world? After all, if financial institutions are forced to open up their systems to literally anyone, how do they retain relationships? How do they keep from becoming nothing more than an engine that processes account information, while leaving the digital experience to fintech players and other new entrants to the market who don't live under the regulatory scrutiny that financial institutions live with?

To be fair, I totally understand the resistance to making a banking system accessible in this manner. However, it's important to understand that this is already happening in our industry every day. Products like Mint, Yodlee, and Quicken may log in to members' accounts each day to harvest information—despite not having a relationship to the FI. They simply mimic a member logging in through the home banking platform and then harvest the information on behalf of the member. In this process, the financial institution is getting the short end of the stick in terms of the value exchange. The harvester gets their customers' valuable data. The harvester gets the transaction history of the customers, including what they bought and where. The harvester also collects the account balances and credit card rates and terms so they can cross-sell another credit card to the bank's customers. Meanwhile, the FI loses the ability to the market to this customer without paying to have banner advertisements inside Mint, Yodlee, and others. The FI also gives valuable information to competitors who use the credit balances and other data to make offers to the customer to move their accounts to their FI. So, if this is happening already, then why bother creating an API? Answer: Because if you don't do it, someone else will.

As you can see, they are very open about their strategy to be an open API to anyone. I also found it interesting that they believe community plays an important role in the institution. These two things go hand in hand. Being open means that there will be a community, like it or not. People will coalesce around the opportunity that you are providing them and create something from nothing. We see this behavior in open source platforms where like-minded people collaborate to improve a software or service and donate their time for free.

The first step to solving this problem is to implement your own API to your bank or credit union. This should allow third parties to do everything that you do inside of your own products. Don't worry about who is going to get access to this right now; that's not as important as creating a complete interface. This interface is going to be foundation for everything you will do for the foreseeable future. Let's call this interface the FI platform. You may think that you have something like this in place already, and it is possible that you do, but before you just flip past this part, answer these questions to determine if you really have full featured and ready for prime-time industry grade API that can be used by others to create valuable services for your customer. If you are a CEO or a FI executive log into the companion website and download the following API readiness report and share it with your IT area:

  • Does the API have access to all of your systems? If it is, then the API should be able to execute a command like GETALLACCOUNTS for a single customer and data will be retrieved from each individual system such as a Mortgage servicing platform and a Credit Card platform without having to make separate calls to each of these systems.
  • Is your API fully documented? Would you feel comfortable giving this document to a business partner?
  • Does your API support all the features that your digital platforms currently support? Can it create a new Billpay payee or add a ACH payment? Can you reset a password with it?
  • Is your API securely accessible via VPN or via the Web using state-of-the-art security such as oAuth2 or SAML?
  • Does your API provide account level security that can limit access to any service?
  • Is there business logic that your API should have but doesn't? A good example would be ACH processing days. If a vendor uses the API to setup a ACH payment and tries to schedule it for a fed holiday, will it go through without notifying the vendor that the payment cannot be processed on a fed holiday?
  • Does your API support universal logging and reporting?

If you answered no to any of the questions above, then you have some work to do. A true API will have all of these features and more. You might be thinking that this is going to be a really long road. Don't fret: There are answers out there.

Getting Started

For the Technology Organization

There are software packages such as MuleSoft and Software A&G that you can purchase and create the API with your development staff. These are considered enterprise grade products and will solve most of the problems above. These products ride the line of being a pure product and being a toolkit that your IT staff can use to create the platform that you desire. You can also reach out to your industry peers to see if anyone has developed or is developing something similar for your platform. Sometimes other FIs will gladly accept the help of FI that isn't a direct competitor to share cost of creating such a platform in the form of a purchase of the application.

For the Services Organization

There are full-featured packages that can be deployed and allow you to expose your various systems via API. Many times, these sorts of API platform packages will be provided by your core data-processing solutions providers; otherwise, there are also third-party platforms that do the same thing, such as Finnovations Concerto platform. I would suggest reaching out to your core solution provider first then if they don't have something check with your industry peers to find out if anyone is using a third-party platform that they really like and that supports your core data-processing provider.

The Second Step

Now that the FI platform is up and running, it's time to cut off the free access that the third parties have been getting to your data on behalf of the customers. This is a relatively simple thing to do technically but far trickier in terms of marketing and customer service. For the technical side, have IT review your logs and find out the IP addresses of the systems that are scraping your data. It's usually simple to see these patterns in the logs, as these bots tend to move at a speed that no human could ever duplicate and tend to come in mass at odd times in the early morning (which is very nice of them, btw—they could run it at your peak time and add extra stress to your system). These IP addresses will also likely be associated with multiple customer accounts. Have your IT folks track down all of customers' accounts associated with these IPs as your team will need them to inform customers that the products they are using will stop working soon. You will also need to perform a WHOIS on these IPs to determine which vendors your marketing department needs to call to start the conversation of having them access your API instead of going through your home banking or mobile platform to obtain your customers' data. One of the main reasons that they should be open to having a relationship with you is that the process they are using now is very clunky and highly susceptible to failure due to its dependency on the placement of data on the screen in the home banking site (which can often be moved around by the customer, as already mentioned). This methodology will also break if it encounters a Multi Factor question or out of band password request. The customers often must regularly intervene to keep these services working properly.

The Third Step

This is where it gets interesting. Now it's time to turn the tables on the harvesters or scrapers. Here is where you need to stand firm. Have your staff contact each of the entities that are screen scraping your customers' data and let them know that you will be blocking them from your system on this date and time in the future. However, you can also inform them that you have a new way for them to access the data and for a price of <insert amount here> per customer they can pull the data in a far more efficient and secure way. At the same time, your marketing team will need to contact every one of your customers using these services and let them know that you will be discontinuing access to your platform in their current form due to the inefficient way that these entities access the data. As an added benefit, you can let them know you have a better way for these entities to access the data, and if they truly want to continue using this service, it would be helpful for them to reach out to the entity and inform it of the new process. You can even include a nice cut-and-paste prewritten email for the customers to send to these entities in your correspondence with them.

This may seem like a bold and kind of scary move, and I am sure that when you review the logs, depending on the size of your institution and the demographics of your customers, you will find a large number of customers that use these services. At first, these customers may be dismayed that their financial institution is forcing their provider of choice to use an API, and they may be even more dismayed to find out that you are charging this provider for the access when it has been free up until now. However, it's time to be bold and stand up for your customers and their data. Financial institutions must stop giving things away for free and plan to measure and monetize their data if they are to survive the coming digital transformation. The tragedy is that many of these customers are among your most affluent and profitable, but since they no longer visit your digital sites, choosing instead to visit the site that is harvesting their data from home banking, they also no longer see your advertisements and don't read your secure messaging, in some cases the harvesting entities will turn off alerts in favor of sending them their alerts. Moreover, each time a harvester or scraper accesses data, it cost the financial institution money by putting stress on the infrastructure and creating overhead in bandwidth and increasing storage costs by bloating the logs. In the end, all it really does is put your organization at a huge disadvantage in terms of having the opportunity to increase engagement with customers.

OK, now that you have this magical API or FI platform, it's time to leverage it even more for your customers. It's time to leverage other services and allow consumers to access your data efficiently and securely. Consider for instance the rise of Amazon's Alexa platform. Once considered a toy, it is rapidly becoming a channel of choice for many consumers to get their data, since it is far easier and more natural to interact with voice than it is to type and click on a visual interface. Once you have this FI platform to connect to, you can either find a partner to connect you to the Amazon Alexa platform or build it yourself.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset