API Standardization vs. Flexibility with B2B Payments: NACHA and Bottomline Technologies Sound Off

Banking And Financial Messaging

EmilyRodenhuis HeadshotwFilter

Emily Rodenhuis

Aug 6, 2018

APIs are not new, but the rapid growth of technology in B2B payments has encouraged banks to embrace them as a means of connecting more seamlessly and effectively with technology and customers. In a fintech landscape where rapid innovation can seemingly compete with repeatable standardization, the flexibility and speed to market that APIs provide has increased their popularity. But the topic of API standardization has rapidly become a key discussion point. To talk about this in more depth, we sat down with George Throckmorton, Managing Director at NACHA-The Electronic Payments Association and Doug Cranston, VP of Product Management for Bottomline Technologies.


SP: Tell us about NACHA’s API Standardization Industry Group and the role that fintechs, banks and corporates are playing in it.


GEORGE: NACHA has for years supported and fostered innovation both inside and outside the ACH Network. So in the case of NACHA’s API Standardization Industry Group, we wanted to see if we could implement some level of standardization amongst all of the APIs being created to further support innovation, remove friction and enhance and speed processes within financial services. Today, we have about 100 member companies with a wide variety of organizations represented. There are large fintechs such as Fiserv and FIS, large and small technology providers, and large and small financial institutions ranging from JP Morgan to Team One Credit Union. We even have regulators and smaller innovators as members. They have all come together with a mission to standardize APIs and how they’re offered and to move away from the bilateral agreements that are commonly used now. In the year that the group has been in existence, we’ve built infrastructure for the developer community such as an API gateway. We’re finishing a sandbox that’s integrated into the gateway and we’re working with Accenture to get it all built. This is not for production. It’s so the developer community can learn about these APIs and test them in their applications, can communicate with each other, etc. As a group, our first order of business was to decide which APIs we would focus on first, so we created some categories of API use cases including Fraud & Risk Reduction, Data Sharing and Payment Access. Within those categories, we identified several API opportunities, two of which we’re currently working on. One of them is a standardized account validation API. The second is for financial institutions to communicate with each other when a fraudulent situation arises. Today that’s a very manual process and a big challenge for financial institutions. These are just the first of many standardized APIs we plan to develop as a way to create some structure and order. The way it works right now, fintechs and financial institutions have bilateral agreements in place to support APIs and our position is that’s not scalable. If we can create some sort of standardization, then we can achieve a level of efficiency and some assurance that things will all work in a consistent manner. Coming down the pike there’s a lot of interest in corporate APIs, which are typically provided by a technology provider with the financial institution being the consumer. An example of this would be an ACH API. If you think about how corporates currently function – working at their workstation all day to take care of everything that needs to be done – it isn’t until the end of the day that they log on to their Treasury system and send information to their financial institution. An API would completely change that process by enabling the transfer of information all day long. That would allow payment instructions to be sent to the bank in real time and make it possible for those payments to be processed in real time as well. There’d be no more processing “window” or a separate process to follow—it would all happen automatically. Corporates are very happy with the flexibility that APIs offer, but there can be some frustration around how differently similar processes might be handled across all of their banking relationships.


SP: What do you think is driving the standardization of technology


GEORGE: I think it varies depending on what’s going on around the globe. In Europe and the U.K., Open Banking is getting a lot of press. It’s a mandate that everyone has to comply with so that’s having a big impact. For other countries that don’t have a driving regulatory factor, such as New Zealand, they’re doing what we’re trying to do here in the U.S., although on a smaller scale. They’re trying to prove to regulators that this is an issue they can solve themselves. In the U.S., there’s no doubt that the issue is being driven by customers. Whether commercial, corporate or retail, their needs and expectations are to have control of their information and be able to use it the way that they want. They want to have standardization so they don’t have to manage different processes and rules. That’s what’s driving all of this for them and the time has come where we simply have to listen.


SP: So how does this drive towards standardization impact the ability to be agile and fast to market? Can those things coexist?


GEORGE: Standardization is important for scalability. If you’re a single fintech working with a single bank, then no, it doesn’t make sense. But getting one client up and running is easy. It’s the next 10 clients that are difficult, unless everyone is following the same sort of “recipe” so to speak. Adoption is no doubt faster with standardization. DOUG: You mentioned the U.K. and the Open Banking mandate there. For the most part, the reaction to that has been lukewarm because part of the pitch has been that it’s supposed to open up choice from a consumer perspective, turning bank services into a set of commodities. Challenger banks are pretty excited about all of this, although incumbents aren’t quite so pleased. How are banks reacting to your standardization group? Are they hesitant? What’s their position in terms of engagement and support? GEORGE: It depends on the use case. For something significant like data aggregation, banks are concerned about security, liability and where the data lies. That’s still a pretty heated conversation, with both the fintechs and the banks offering up good points. When we’re talking about things like safety and security or account validation however, banks are much more receptive to those kinds of things. Overall I’m very excited about the level of acceptance that we’ve received from financial institutions. They’re engaged and very interested in making sure they have some influence and that their concerns are addressed. So far we’ve been quite pleased with the discussion. DOUG: So what is the position of your organization around the payment or invoice aspects of this standard as it relates to the implementation of the ISO standard that The Clearing House is proposing? GEORGE: What The Clearing House is trying to figure out is interoperability in a way that can work for all parties. We believe that there’s a standard that would be beneficial there so we’re open to the work that they’ve done and bringing it into our organization.


SP: What are the considerations for fintechs bringing APIs to market?


GEORGE: Early on it was about achieving adoption through strategic partnerships. It’s fine to still do that, but now I think it’s important to understand the value of standardization. For fintechs, not having standardization means that everything is more difficult than it needs to be, from implementations to managing bilateral agreements. Fintechs can look to Google as a use case for standardization. If you want to put Google maps on your website, that API is completely standard, which enabled them to significantly grow adoption. In fact, many banks use that API for their ATM locators. Now of course what we’re working on is vastly different. We aren’t talking about maps but payment and customer data so the level of care is significantly higher. But if we look at Open Banking, part of the problem with that mandate is that there was no standardization required. Banks had to comply but they had no guidelines on how to do it and that would have made things easier.


SP: What are the organization’s plans for the standardization initiative? How does NACHA plan to stay ahead of the evolving needs of the market?


GEORGE: We want to continue to lead and be first to market. We have good momentum with the industry and believe we’re the right organization to be heading up this initiative. We want to expand the APIs available to the industry as well. Getting the first two APIs completed and launched will wrap up a lot of the hard work in configuring the gateway and all the other things you have to do the first time. Then we want to turn this group into a distinct organization with a clear mission. We want to continue to work globally. In fact, one of our first API adoption plans is with Payments Canada. They want to test the account validation API for domestic and cross-border payment instructions. 

EmilyRodenhuis HeadshotwFilter

Posted by

Emily Rodenhuis

Emily Rodenhuis is a creative marketing writer specializing in content creation. Her work has been featured by BankNews, InfoSecurity, AFP magazine and more.
Browse all posts
footer curve