Backed by NACHA, a New Payments Group Works Toward Standardized APIs


July 5, 2017

By John Stewart
@DTPaymentNews

There’s nothing new about application programming interfaces. The code has been around for years, streamlining payments flows between otherwise unrelated apps. Recently, APIs have made possible the seamless integrations that mobile-payments users now take for granted.

But now a group of payments executives are starting to worry that proprietary API specifications could hobble innovation by raising costs and slowing development. “If there are five different organizations, there are five different APIs I have to code to,” says George Throckmorton, a senior director at NACHA, the Herndon, Va.-based governing body for the automated clearing house network.

Higher costs could also hamstring smaller organizations that don’t have the programming resources of large banks and payments companies, Throckmorton adds. “It makes it difficult to have a level playing field,” he says. “We’re not having huge costs today, but the writing is on the wall that this is going to be an issue.”

So in April, NACHA formed the API Standardization Industry Group. The group, which is sponsored by an older NACHA industry group called the Payment Industry Alliance, held its first meeting in May and expects to hold two more this year, one in August in Atlanta and another in October in New York City. The group has grown to include about 100 executives from financial institutions, technology firms, and payments providers.

They are working out not only standards, but also governance issues and matters related to security and legal issues. The end product is expected to be what NACHA calls a “playbook” that will include not only consistent API standards but also a so-called API library with what NACHA calls “use cases and corresponding APIs.”

Throckmorton says the group will reveal in September which APIs it’s focusing on first. It’s using a scoring tool to figure out which ones these should be. “The ones that score higher we’ll work on first,” Throckmorton notes, adding, “One of the first ones will be around fraud and security.”

For now, he says the group isn’t concerned with specific types of payment. Instead, it’s looking at three general areas: fraud and risk; payment access; and payment exchange. As an example of the last area, he cites a problem that has long plagued person-to-person payment systems—how to allow a sender using one network to transfer money directly to a receiver using a completely different network.

“The answer has been to make the receiver join my network,” he says. Instead, standard, open APIs could enable payments to flow network to network just as they now flow from institution to institution within a network, such as in the fledgling Zelle person-to-person payment system launched earlier this year by major U.S. banks.

The first parts of the playbook should start appearing early next year, Throckmorton says.

The API Standards Industry Group’s efforts may well help hold down costs and encourage adoption, but some observers say much depends on the strategies of individual banks. “Standards are clearly one method to facilitate collaboration, so for those areas that banks decide to collaborate, having standards will be valued,” says Nancy Atkinson, principal and founder of Pittsburgh-based GTB Consulting, in an email message. “For those on which they want to compete, standards will be less valued.”

Still, she says both the payments industry and NACHA could benefit by the organization’s decision to stake out an early leadership position on the issue of open payments APIs. “They are assertive in identifying industry needs. They should be congratulated for that positioning. By taking an early lead, they can likely cement their role in this regard,” she says.