FinLync Infographic: Bank APIs vs. Legacy Connectivity Chart

Data Flow

Bank Portals became available in the 1980s and 90s and they’re still used today. Bank portals offer static data: corporates login to the portal, export files and then import them into various systems before they can be used. 

Host to Host or SFTP, which includes SWIFT,  makes a distinction between the delivery channel and the data moving through it. Separate data files move within the delivery channel. The files are sent only 1 or 2 times per day on the bank’s schedule and include traditional file formats like MT, XML or CSV — the majority of which don’t allow for rich data like invoice information, or are limited to only one language, usually English.

In host to host, files are a one-way push from the sender to the receiver, and both parties typically rely on fileservers to store the files until the receiver picks it up. Once a file has been sent, the receiver needs to constantly check if a new file is waiting for them in the fileserver, then when it finally arrives, they have to pick it up and move it to its next destination.

Bank APIs are a 2-way conversation where the connectivity channel and the data are one in the same, whether you connect to a single bank or want multi-bank connectivity. There are no files — which means it’s secure, has a lightweight set-up and comes with little to no ongoing maintenance. As a message is sent, the bank API responds in the same action at the same time with the response. It’s no longer 2 separate actions within a one way data exchange, but a single synchronous message – request and response — all at the same time. Data can be requested at any time on-demand, again and again, just by hitting refresh.

Security

Bank Portal security is limited to physical tokens, and the process is highly vulnerable to internal and external fraud. Using bank portals can pose a serious compliance risk because they lack an internal audit trail.

Host-to-Host is file-based connectivity, which is highly vulnerable to fraud. Because host-to-host connections accept file formats of any type, there are no forced data or security standards, leaving it vulnerable to data manipulation or malware injection attacks. Then there are the fileservers. At some point in the life of the file, an administrator will need access to it. Because host to host connections separate the interface and the files, the data in that file could be manipulated before any encryption occurs. Setting up a host to host connection is no easy task, so corporates often purchase a 3rd party system with pre-built host to host connections. These third parties act as middlemen, cobbling together host to host connections that relay data onwards to other host-to-host connections, Swift, or to the bank. This adds yet another insecure link in the connectivity chain, further increasing the security risk.

Bank APIs are today’s most secure form of technical communication between two parties. They leverage the latest and greatest in technology and enterprise security standards. The security is built into the channel and the data – since they’re one in the same – and includes multiple types of security like certificate exchange, user credentials and data encryption. With bank APIs there are no files, since the data and the delivery channel are one in the same, so there’s no way to intercept or compromise the data.

Data Management

Bank Portals are entirely manual. Each time data is needed, someone must manually log into the portal using their tokens, locate the type of data they need, export it and then upload into the system of record.

Host-to-host bank connectivity was never designed for real-time connectivity. Files need to be polled for, and the process was created to move large batches of data, not individual transactions. For every file sent through host-to-host, there’s a 6-step process involving the bank and the corporate. This lengthy process doesn’t provide confirmation that the file has been sent successfully in the first place, nor that it successfully arrived to the recipient. It’s common to not receive an acknowledgement, leaving corporates in the dark, wondering if the bank actually got the file in the first place. And if a file needs to be re-sent, the company has to manually call or email the bank to request it.

Bank APIs were designed for real-time data exchanges from the start. The connection between 2 counterparties allows each counterparty to remain in control of their data by requesting what they want, when they want it. Bank APIs don’t need fileservers because there are no files, just a stream of data designed to naturally flow between systems. And their messaging formats are lean because they use JSON (JAY-sahn), a data interchange format that supports new and different types of data such as all global languages and enriched data – like invoice information.

Processing Data before Use

Data from bank portals must be manually accessed, manually exported and manually imported before it is even started to be used. Host-to-host requires a similar preparation method because it remains file-based. With Bank APIs, the data is always ready to be used and can be refreshed as many times as you want, whenever you want.

Data Freshness

Bank Portals offer data that begins going stale the moment you export it from the portal. Obtaining fresh data is cumbersome to access and to reincorporate into your work midstream.

Host-to-host connections offer data on the bank’s timeline, not yours. Though scheduled statements can offer data updates at certain times of day, it still doesn’t paint the most-accurate picture because you’re working from stale data with at least a few hours of lag time, or even a few days.

Bank APIs provide up-to-the-minute data on-demand. With this type of connectivity you always know what the latest is, and you can refresh that information with a click of a button.