What is bank connectivity?

Introduction to bank connectivity

Bank connectivity is foundational to most if not all financial and treasury operations, enabling companies to pay their bills, get paid, and manage cash efficiently. For a more detailed analysis of this topic, read our guide to bank connectivity. 

Fundamentally, bank connectivity concerns how a company exchanges data or information with its banks. A basic requirement for a treasury team is the ability to access account balances, transactions, and payment capabilities across all of their company’s banks.

This is not a new responsibility for treasurers. For most of the twentieth century, banking information was sent and received using paper documents. Transactions were recorded in a physical ledger, bank statements were sent in the mail, and payments were executed in person or over the phone.

Nowadays, bank connectivity fully automates these tasks. Companies can receive information from banks and send payment files to them using the same connection over the internet. The alternative is to manually log into a number of bank portals each day, export the data into a spreadsheet, and upload payment files or enter the payment information by hand.

We covered these kinds of manual treasury processes in an earlier guide, but they can be time-consuming, prone to errors, and fraught with risks.

‍

Bank connectivity options

Host-to-host

Host-to-host (H2H) connectivity enables companies to securely send and receive data to and from their banks. It is an established connection method that functions as a private data highway between a company and a specific bank.

A host-to-host connection is a direct communication link between two computer systems, used as a method of securely transferring files between a client and a server. A common type of host-to-host connection is a Secure File Transfer Protocol (SFTP) with IP whitelisting.

Host-to-host remains the preferred choice for many companies since it is fairly simple to set up and maintain but the files that a company exchanges with its bank can contain large amounts of detailed financial information. This can be crucial in helping you automate bank reconciliation processes.

The quality of the data received through a host-to-host connection depends on the sending bank. Requesting changes to bank files and formats can be a slow process. Additionally, some banks only offer host-to-host services to corporate enterprise clients – smaller companies may find they’re expected to export files manually from the bank portal instead.

Host-to-host is regarded as one of the slower methods of bank connectivity since most banks send files daily or on an intraday basis, as opposed to data being available in real time.

For more information, see our dedicated article on host-to-host connectivity.

Electronic Banking Internet Communication Standard (EBICS)

EBICS (Electronic Banking Internet Communication Standard) is a standard protocol that enables companies to connect directly to a specific bank over the internet, as with a host-to-host connection. It uses digital signatures and encryption to secure the data and incorporates data from a broad spectrum of financial transactions including payments, collections, and reporting. 

Though the ambition is that EBICS becomes the standard for bank communication across the SEPA zone, today it is predominantly offered by banks in Germany, Austria, Switzerland, and France. Banks in other countries, including some outside Europe, are known to be testing it though.

One of the benefits of EBICS is that companies can, in theory, connect to multiple banks using a single protocol, unlike host-to-host which requires a unique connection to each specific bank. In reality, there are local EBICS variants in use in certain countries and not all banks follow the latest standard, EBICS 3.0.

Nonetheless, EBICS does help standardize bank files and formats across different banks and their systems, simplifying integration when connecting to multiple banks.

You can find more information in our longer post on EBICS specifically.

SWIFT network

SWIFT (Society for Worldwide Interbank Financial Telecommunication) is a global cooperative network of banks and financial institutions founded in Belgium in 1973. SWIFT provides a messaging system to standardize financial messages between its member institutions, which companies can connect to as a gateway to over 11,000 financial institutions in more than 200 countries.

SWIFT’s network, known as SWIFTNet, is global, secure, and highly reliable. By acting as a single gateway to so many banks, SWIFTNet can greatly simplify bank connectivity for companies, enabling them to change banking partners at will without having to worry about establishing new connections.

The downside of using SWIFTNet directly is the cost and effort required to build and maintain a direct connection to the network. The integration requires considerable engineering resources and know-how. Plus, you need to comply fully with SWIFT’s security policies. Consequently, most companies that rely on SWIFT use a third-party provider or service bureau to whom they effectively outsource their bank connectivity.

To learn more about SWIFTNet connectivity, see this article.

Corporate banking APIs

An API (Application Programming Interface) enables two pieces of software to interact and communicate with one another. APIs are intermediaries that enable different applications and systems to share data with each other in a standardized way.

Today, APIs are developed by a growing number of banks to allow programmatic access to their banking services. The push for banks to start offering their own proprietary APIs began in the late 2000s, driven by a combination of regulatory changes, technological advancements, and the need for banks to meet evolving customer expectations. 

While the APIs offered by banks do not adhere to a single standard, they frequently use ISO 20022 for message exchanges. What sets the use of banking APIs apart is their capability for real-time transaction processing. The moment a payment is initiated, the API calls are activated to process the transaction, validate customer credentials, and update account balances. Often, this all happens in under one second.

Revolut is an example of a financial institution that offers a premium corporate API to business customers. By integrating with Revolut’s API, Atlar is able to process customer account data securely and in real time. Atlar customers can access this data and make payments in the Atlar dashboard, even automating payments using workflows that incorporate their company’s own applications.

Integrating with and maintaining an API connection requires engineering expertise, but it lets companies manage their finances in real time as opposed to accessing data that is 24 or 48 hours old. You can find more information about banking APIs, real-time payments, and how Atlar supports both in our guide to treasury tooling or by reading our full post on bank connectivity for finance teams.

Open banking

Open banking APIs have grown in prominence in recent years, ever since the Payment Services Directive (PSD2) came into force in 2016. PSD2 sets rules governing how third-party providers can access the payment and account data that banks store on their customers. It obliges banks to give third parties access to your account if you give your consent.

In some countries, like the UK and Sweden, the number of banks offering an open banking API has proliferated over the last few years. These APIs are mostly designed for consumer use cases, such as connecting your bank account in order to apply for a mortgage, verify your identity, or make a payment. Regulated PSD2 service providers, known as an Account Information Service Provider (AISP) or Payment Information Service Provider (PISP), connect to these APIs to make the services available to the end user.

‍

Key success factors in implementing bank connectivity

Payment capabilities

Established connection types such as H2H, EBICS, and SWIFT generally offer the full range of payment capabilities. They support a wide array of transaction types, including bulk payments, international transfers, and multi-currency payments, along with automated tracking and error handling. These methods are also known for their security and reliability, making them ideal for large and complex transactions.

For APIs, the payment capabilities depend on the maturity of the bank’s API. Open banking APIs, in general, do not yet support a full range of payment services and are often less well-maintained compared to banks' premium corporate APIs. Additionally, when using open banking in Europe, there is a mandatory Strong Customer Authentication (SCA) step enforced on every payment.

Data quality

H2H, EBICS, and SWIFT typically provide high-quality data due to their direct connections with banks, ensuring reliable and accurate data transfers. Well-developed APIs can also deliver high-quality, potentially real-time data, but less mature APIs often result in inconsistencies.

Corporate banking APIs vary in the data they support, from minimal (basic account balances) to more comprehensive datasets. Open banking APIs generally offer the least data, often excluding account types not mandated by open banking regulations, such as business or non-transactional accounts. The quality of open banking APIs can be inconsistent, as some banks do not maintain them properly.

Ongoing data reliability issues can slow the adoption of a new treasury system and reduce its ROI. At Atlar, we prioritize ensuring our connectivity is reliable from day one, with an uptime of 99.99% and above – see our status page.

Time and effort to implement

Whether you manage it internally or rely on an external consultancy service, setting up bank connectivity can be a long and costly process.

Establishing a single connection requires a complex integration project, coordination with the bank, configuration tasks, and ongoing maintenance. Since each bank uses its own unique systems, this process is seldom repeatable. Managing multiple implementations simultaneously can be challenging, as it depends on the bank prioritizing your company in their task queue.

It's important to note that most treasury software providers, unlike Atlar, hold the customer responsible for the end-to-end implementation or charge an additional service fee to manage it themselves. Consequently, companies often hire external consultants at significant cost to handle the process.

Scalability

To avoid disruptions and costly overhauls, a connectivity partner should be able to scale with your company as it grows. It should be able to support various connection methods across multiple countries, as well as both real-time API connections and more established methods

This also allows for easier switching between banking partners as business needs evolve. A treasury system with limited connectivity can lock a company into suboptimal banking relationships and make it harder for companies to benefit from the latest technologies. Some legacy TMS providers, for instance, lack support for real-time API connections.

Integrating other systems

A potential bank connectivity partner should be capable of integrating with your company’s other systems, especially its Enterprise Resource Planning (ERP) or accounting system. Although some ERPs offer bank connectivity, these connections often lack essential functionality for treasury management.

Using a treasury platform like Atlar to connect your banks and ERP allows you to automate financial processes end-to-end. Bank data and account statements can be automatically pushed to your ERP, simplifying reconciliation. Payment runs can be initiated directly from the ERP, eliminating the need to transfer payment files or log into multiple bank portals.

Atlar can integrate with any payment platform or finance system that offers an API, such as a payment service provider (PSP) or an expense management tool, and has prebuilt, no-code integrations with Oracle NetSuite and Microsoft Dynamics.

‍

How Atlar can help with bank connectivity

Atlar has prebuilt connections to over forty major banks globally, covering a variety of methods including SFTP, EBICS, and API. What’s more, Atlar handles all implementation work on behalf of its customers, from onboarding to testing and go-live. Depending on your banks, this potentially equates to hundreds of hours saved.

It also results in significantly quicker implementations. Atlar customers enjoy full bank connectivity within 2-3 months on average – without any consultants, implementation work, or additional fees – compared to 6-18 months for a legacy treasury system (typically with a large consultant bill).

Bank connectivity can be a tough nut to crack, but not if you find the right partner. To speak to one of our experts on the topic, simply book a demo here.