by Ben Dwyer While application programming (APIs) have long been basic components of communication between different apps, there is not yet standardization for them.
Now the governing body NACHA – formerly known as the National Automated Clearing House Association – aims to change that by launching the API Standardization Industry Group (ASIG) to develop an “API Playbook.”
Let’s take a look at what API standardization would mean and how it would function.
What is an API?
First things first – what exactly is an API, and what is its use? The API is the method of communicating, for example, with a credit card processing company. Not long ago, a person could telephone a company with credit card information to place an order. Now, online ordering uses the internet. A conversation between computers is done in place of the telephone and people, but similarities exist. In a phone call, you have to identify yourself and describe the type of transaction you want to complete. The person you speak to will inform you if they can complete the transaction.
Typically, a credit card request involves a specific amount of dollars from a credit card, the card number, and an expiration date. The company handling the credit card request lets the business know if the credit card number is valid, if it was reported stolen, and if the limit on the card is sufficient for the desired amount. The business then decides what to do, based on the reply. If all parties approve the transaction, the business will process the order. If the transaction cannot be completed, the business must decide what action to take. For example, if the dollar value exceeded the card’s limit, you could save the order as a back-order for future processing or cancel the order.
Using APIs
Programs use APIs through multiple languages, such as Ruby, Python, Node.js or PHP. Programs communicate in what’s called a client-server request-response protocol, referring to a system where one side sends a request and then the sender receives a response to the request.
Processor APIs
The company you chose for your processing will have lots of documentation on how to use their APIs. They will have sample scripts you can copy and then modify for your own usage. One caveat: You cannot blindly copy and then change a name or account code. You need to understand the code since you’ll use it for secure money transfer. You’ll need to follow all coding standards that relate to security and the prevention of misuse.
Every time a call is made to an API, you need to be able to interpret the response status code. You are probably familiar with the code 404. This is when a browser cannot find the webpage you are looking for. An API’s documentation will define what possible responses can be received.
API Steps
Here are some of the steps that an online system might use to process an order:
- The start of the conversation with Authentication. This identifies you with the company. It will usually involve you providing an API key and an API secret key.
- When authenticated, you will have a token which will expire after a set amount of time, perhaps 5 minutes. If it has expired, it will send back a status code.
- The requests for the transactions to debit or credit an account will also have multiple response codes for interpretation.
The complexity increases if you have to understand/interpret each service provider you deal with. You may be processing for credit cards, credit by bank and account number, or by email address. And if you switch providers, you will need to understand a different set of API specifications.
For order processing, the API for the financial transaction may be linked to your supply chain and accounting systems so that if the order is successfully placed, then your financial data and your inventory are updated.
Yes, the process is complicated, and unless you’re a developer, it’s hard to grasp. The lack of standardization makes API even more complicated than necessary. NACHA hopes to address that through standardization of APIs.
What Standardization May Achieve – the Initial Meeting
In May, 2017, the members of ASIG held their first meeting at NACHA’s Herndon, Virginia offices. Representatives from 33 companies attended, including Visa, Bank of America, Merrill Lynch, J.P. Morgan, the Navy Federal Credit Union, ADP, U.S. Bank, and other major financial industry players.
The meeting’s summary notes that API adoption within the financial services industry has not incurred en masse. While there are other reasons for the lack of complete adoption, such as inadequate cost/benefit analysis information and insufficient leadership commitment, the lack of API standardization appears the most compelling argument.
The NACHA posits that standardization is “transformational” for financial payments and services. Such standardization improves transactional safety and automates communication and processes, according to the NACHA. The proposed API playbook should create a standardization system beneficial to all parties by addressing the needs of businesses and improving payment support.
Timeline
The plan is to have the initial parts of the API playbook available in early 2018. However, ASIG notes that the playbook cannot succeed without acceptance of the “critical mass.” At the inaugural meeting, ASIG members posed questions integral to the adoption of the API playbook. These include regulation, and the forced adoption of the playbook via such regulation; how standardization affects competition, and, if so, how that presents an obstacle to adoption; keeping the playbook relevant and meeting changing needs of the finance industry and whether standardization is always necessary. There’s another huge concern: Security. Ensuring the security of an API “ecosystem” is paramount. Security is a critical issue now, without standardization. Will even the most sophisticated standardized security present greater problems than the individual security systems currently in place?
Current Pain Points
Standardized API could solve various pain points outlined at the meeting. ASIG is focusing on three primary areas to start:
- Security and fraud – securing confidentiality of payments and payor/payee validity confirmation
- Payment access – supporting interconnectivity of diverse real-time payment systems
- Data sharing – including APIs containing all necessary information about individual payor/payees and single sign-ins for multiple platforms
Future areas ASIG plans to address include portability for consumers and businesses to open accounts, along with directories enabling payments by virtue of an email address, similar to the Zelle payment service. The ASIG also wants to ensure that “unbanked” individuals and smaller business entities benefit from API standardization. For the former, that may involve providing services for people without a bank account as easily as those with demand deposit accounts. For the latter, standardized APIs should lessen the gap for payment functionality between small and large businesses. Once standardization occurs, all financial institutions are equally accessible. ASIG wants to coordinate all API standardization efforts to avoid duplication by other parties, so that there is indeed a standard and not duplicate versions of the same intention.
Further 2017 ASIG meetings take place August 24 in Atlanta and October 11 in New York City. The ASIG will provide updates both to inform the financial services industry of its progress and to elicit feedback from interested groups.
NACHA’s Payments Innovation Alliance (PIA) sponsors ASIG. PIA “brings together diverse, global stakeholders to support payments innovation, collaboration, and results through discussion, debate, education, networking, and special projects that support the ACH Network and the payments industry worldwide,” according to NACHA.
