A guide to bank connectivity for finance and treasury teams

Bank connectivity lets companies perform key tasks – pay their bills, receive payments, manage cash, and forecast cash flow – in a more automated way with the use of technology. The alternative is to log in to each bank portal individually, manually transfer files, and compile the data in spreadsheets. Many companies find this too error-prone and time-consuming: Atlar customer Loomis Pay used to spend over 100 hours a week on these processes, while the team at Sellpy spent 60 hours a week.

It’s true that achieving complete bank connectivity can be time- and resource-intensive – it can take between 6-18 months to connect a traditional Treasury Management System (TMS) to multiple banks, for example. Banks use different systems, protocols, and file formats, and many still rely on legacy systems that require extensive coordination and support.

We understand the work involved. Unlike many treasury platforms, Atlar handles the entire implementation for its customers and today offers prebuilt connections with all major banks and payment providers, spanning all major connection methods. This guide covers the pros and cons of each method in detail – if you’re interested in learning more about how we help customers like GetYourGuide and Acne Studios with connectivity, get in touch.

‍

What is bank connectivity?

At a basic level, bank connectivity is about how a company exchanges financial data and payment instructions with its banking partners. For most treasury teams, it’s essential to have both data access and payment capabilities to perform basic cash management activities.

Consolidating financial information and moving money is nothing new for treasury professionals. Traditionally, transactions were recorded in a physical ledger, bank statements were sent in the mail, and payments were made in person. Nowadays, bank connectivity means these activities can be fully automated. Companies can receive information from banks and send payment files over the internet – freeing up time, increasing security, and enabling smarter financial insights.

Bank connectivity methods range from legacy options like SWIFT to established methods like host-to-host (H2H) and newer options like APIs. The emergence of APIs is a key trend: when these APIs are complete and mature, as with some corporate banking APIs, they unlock the ability to manage cash and make payments in real time. H2H remains the gold standard in connectivity for the time being, though, and H2H connections are often used interchangeably to refer to connectivity in general.

‍

The alternative to bank connectivity: manual processes

The alternative to bank connectivity is to rely on manual treasury processes for payments, data collection, and reporting. This means logging into each bank portal individually in order to enter payments or export data and upload it into a spreadsheet. These processes are manageable for startups and small businesses but are time-consuming, prone to errors, and fraught with risks.

Manual cash positioning, reporting, and forecasting

Without bank connectivity, consolidating a company’s financial data can be cumbersome. It means logging into multiple bank portals or payment systems, exporting balances and transaction data, and then compiling this in a spreadsheet.

Some data may need to be reformatted and there are often one or two errors. Forecasting or analyzing cash flow requires you to review each transaction and categorize it manually before manipulating the data in a spreadsheet. If your company has multiple entities or banks, the entire process can consume several days.

Because manual cash positioning is so time-consuming, companies usually do it at fixed intervals rather than on an ad hoc, real-time basis. The resulting monthly, quarterly, or annual reports are a snapshot in time that quickly become outdated – and are not timely enough for most modern, agile companies.

Manual payments

A manual payment involves logging into the appropriate bank portal, entering the counterparty and reference information by hand or uploading a file (usually downloaded from an ERP), and initiating the payment or sending it for approval. Since most businesses need to make treasury, supplier, tax, and salary payments regularly, it can require someone dedicated to the task full-time.

The problem is multiplied if you use multiple banks, since you need to log in to and navigate each system separately. Tracking each payment manually, resolving any errors, and retrieving the transaction details for your internal records can take significant time.

Manual payments also expose a company to risks. You need to grant more and more team members access to bank portals and there’s a higher risk of data entry errors. Without approval chains in place, you have to wait for a single approver to sign every payment – or make do without any payment controls at all.

‍

Key factors in getting bank connectivity right

The ability to access account balances, fetch transactions, and initiate payments at all of their banks is a basic requirement for modern treasury teams. But not all bank connections are created equal: some methods have limitations for certain tasks, and some can be time-consuming and costly to implement if not managed well. Here are the key factors to consider.

Data quality

Connectivity methods vary in the quantity and quality of the data they provide, which can determine the usefulness of a treasury system. Having access to a complete, error-free data set is a prerequisite for accurate reporting, forecasting, and planning.

H2H, EBICS, and SWIFT generally offer high-quality data due to direct connections with banks, ensuring that data is transferred reliably and accurately. Well-developed APIs can also offer high-quality data, potentially in real time, but less mature ones often produce inconsistencies. Open banking APIs in particular can vary in quality as some banks don’t maintain them sufficiently.

Similarly, H2H, EBICS, and SWIFT connections support the largest quantity of data, including detailed balance and transaction information plus other metrics for all types of accounts. Corporate banking APIs can range from minimal data support (basic account balances) to a more comprehensive dataset. Generally, open banking APIs offer the least amount of data. Account types that are not mandated by open banking regulations, such as business accounts or non-transactional accounts, might not be included at all.

Ongoing data reliability issues will harm the adoption of a new treasury system and lower its ROI. At Atlar, we take great care to ensure our connectivity works reliably from day one with an uptime of 99.99% and above – see our status page.

Payment capabilities

Established connection types like H2H, EBICS, and SWIFT typically provide full payment capabilities. They support a wide range of transaction types, including bulk payments, international transfers, and multi-currency payments, as well as automated tracking and error handling. They are also known for being highly secure and reliable, making them suitable for large and complex transactions.

When it comes to APIs, the payment capabilities available vary depending on the maturity of the bank’s API. Open banking APIs do not yet support a full range of payment services, generally speaking, and are usually less well-maintained than banks' ‘premium’ corporate APIs. Additionally, there is a mandatory Strong Customer Authentication (SCA) step enforced on every payment when using open banking in Europe.

Time and effort to implement

There’s no way around it: connecting to banks requires significant engineering resources and technical expertise. Whether you manage it internally or rely on an external consultancy service, it can be a long and costly process.

A single connection involves a complex integration project, coordination with the bank, configuration work, and ongoing maintenance. Given that each bank has its own systems, the process is rarely repeatable. Coordinating multiple implementations at the same time can be challenging since you are dependent on the bank prioritizing your company in their task queue.

Be aware that most treasury software providers (Atlar not included) hold the customer responsible for the end-to-end implementation or charge an additional service fee to manage it themselves. Companies often hire external consultants at significant cost to handle the process instead.

Given the complex nature of these projects, it is all too easy for them to spiral into a years-long project before seeing any ROI from a new treasury system. According to a 2019 Deloitte report, on average it takes up to 18 months before a TMS is implemented with full bank connectivity. By contrast, Atlar customers are up and running in 2-3 months on average.

Integration with other systems

Any potential bank connectivity partner should be able to integrate with your company’s other systems, particularly its Enterprise Resource Planning (ERP) or accounting system. ERP connections usually run on host-to-host or API. Some ERPs do provide their own bank connectivity, but often the connections lack basic functionality for treasury management.

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

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

Flexibility

It’s key to choose a software provider that can connect to all of your banks, now and in the future, in order to avoid disruptions and costly overhauls. This means it has support for various connection methods across multiple countries, as well as both real-time API connections and more established methods, depending on the optimal connection type for each bank.

A flexible connectivity partner 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, limiting flexibility and negotiating power. Some legacy TMS providers, for instance, lack support for real-time API connections, making it difficult to benefit from improvements in API reliability and access to real-time data.

The Atlar platform is built from the ground up to support both API-based and traditional bank connectivity methods – and at scale. The Fundcraft team, for example, successfully connected over 100 bank accounts with 100% of bank onboarding and implementation work managed by Atlar.

Host-to-host (H2H)

H2H connectivity has long been considered a gold standard in bank connectivity and remains so to this day. It enables companies to securely send and receive large volumes of financial data to and from their banks and has been relied upon by corporate treasury teams for a number of years.

How host-to-host works

H2H connections are a direct communication link between two computer systems, used as a method of securely transferring files between a client and a server. A connection functions as a private data highway between a company, or its treasury system, and a specific bank.

This direct connection allows for automated data exchange without the need for manual intervention. Standardized file formats such as ISO 20022 and BAI2 are used to exchange a full range of financial data including payment instructions, account statements, balance reports, and transaction details.

Security is built into H2H connectivity by design. Encryption, digital signatures, and secure channels help to protect sensitive financial data as it’s being transmitted, while authentication solutions such as VPNs are used to ensure that only those authorized can access the data. 

Secure File Transfer Protocol (SFTP)

One of the most common types of H2H connection is a Secure File Transfer Protocol (SFTP) with IP whitelisting. Other types do exist, such as FTPS, HTTPS, and older protocols like EDI (Electronic Data Interchange, but SFTP is generally preferred. 

The process to set up an SFTP connection is as follows:

1. Establishing a connection: An SFTP client (a company's treasury or ERP system) creates a connection to an SFTP server (the bank’s server) over a secure channel.
2. Authentication: The client and server authenticate each other using SSH keys or credentials.
3. Encryption: All data transferred over the SFTP connection is encrypted using strong encryption algorithms, ensuring confidentiality and integrity.
4. File transfer: Once authenticated, files can be uploaded, downloaded, renamed, deleted, or managed on the server at will with all commands executed securely.‍
5. Automation: SFTP can be readily automated using scripts or software tools to schedule and manage file transfers. The data exchanged can be processed as soon as it is transmitted and made available to the end user.

Pros and cons of host-to-host

H2H remains the preferred choice for most companies since it’s relatively straightforward to set up but the files transferred can contain large amounts of detailed financial information. Battle-tested over many years, H2H connectivity like SFTP is known for its reliability in supporting critical financial operations.

The quality of data received via H2H depends on the sending bank, but most banks have well over a decade of experience in supporting it. Requesting changes to bank files and formats can be a slow process, though. Additionally, some banks may only offer H2H services to corporate enterprise clients.

H2H does not enable real-time data access, since most banks send files daily or on an intraday basis. Nonetheless, H2H is regarded as a must by many treasury departments because of its unparalleled reliability and the relative ease of setting up a connection, thanks to years of standardization and use.

• Pros: A highly reliable method for transmitting financial data efficiently and securely. Trusted by businesses of all sizes, H2H is ideal for most payment and treasury operations.‍
• Cons: Data is usually sent by the bank on a daily or intraday basis. Though that is sufficient for most treasury use cases, the data is not made available in real time.

‍

Electronic Banking Internet Communication Standard (EBICS)

EBICS is a standard protocol that lets companies connect directly to a specific bank, as with a H2H connection. When available, EBICS is often the most reliable and efficient option because it is highly standardized, ensuring compatibility between different banks and companies, and supports a wide range of banking transactions. The main drawback is its availability: EBICS is not yet widely supported outside Germany, France, Austria, and Switzerland.

How EBICS works

EBICS is a standardized protocol for electronic banking that enables secure communication between a company and its banks. It requires technical expertise to set up initially, but once in place it can help simplify connections to other banking partners that also support EBICS.

Digital signatures and encryption are used to secure the data, which covers a broad spectrum of financial transactions including payments, collections, and reporting. EBICS uses standardized XML formats with common message types as well as MT (SWIFT) messages.

The process to set up an EBICS connection is as follows:

1. Registration: The company registers with its bank(s) to use EBICS. This process involves exchanging public keys and setting up user accounts.
2. Authentication: Users are authenticated using secure methods such as a password, PIN, or cryptographic token and provided with unique credentials.
3. Secure communication: Data shared between the company and the bank is encrypted and each message is signed digitally to verify that it comes from a trusted source.
4. Data processing: Transactions are initiated from the company's ERP or TMS, formatted according to EBICS standards, and sent to the bank via the EBICS client. Once validated, the bank processes the transactions, such as executing payments or updating account balances.
5. Automation: As with H2H, EBICS supports automated processes for initiating transactions and retrieving data, reducing manual work.

Pros and cons of EBICS

EBICS allows companies to set up direct connections with multiple banks using a single protocol, unlike H2H which requires a unique connection to each specific bank. The ambition is for EBICS to become standard across the SEPA zone, but in reality it’s mostly limited to banks in Germany, France, Austria, and Switzerland. Even in these countries, some banks use local EBICS variants and not all follow the latest standard, EBICS 3.0.

Companies should look to use EBICS when it’s available, though. Thanks to its standardized formats and message types, it is one of the most robust and efficient connectivity methods and can help simplify the implementation process. The effort required to set EBICS up initially is comparable to a single H2H connection, but thereafter it can simplify connectivity with other EBICS-supporting banks.

• Pros: A reliable, secure connectivity method that can potentially allow companies to connect to multiple banks using a single protocol.
• Cons: EBICS is predominantly supported in Germany, France, Austria, and Switzerland – limiting its usefulness for international companies – and requires engineering resources and coordination with the bank during setup.

‍

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 members, which companies can connect to as a gateway to over 11,000 financial institutions in more than 200 countries.

How SWIFTNet works

SWIFTNet, specifically its FIN service, uses standardized message types to ensure consistent and reliable communication to and from the 11,000 financial institutions that are members. Common message types include MT103 (credit transfer), MT940 (account statement), and MX pain.001 (payment initiation). Transactions are authenticated using BICs (Bank Identifier Codes) and digital signatures to verify the sending and receiving parties.

The services provided by SWIFTNet include:

• FIN: SWIFT’s core messaging service, used for exchanging standardized financial messages.
• InterAct: A real-time, interactive messaging service that supports XML-based and ISO 20022 messages.
• FileAct: Designed for batch processing, FileAct enables large files to be transferred securely in bulk.
• Browse: A web-based interface that lets users access SWIFTNet services online and retrieve reference data. 

Pros and cons of SWIFTNet

SWIFTNet offers global coverage and high levels of reliability and security, with support for a similarly wide range of financial messages as H2H and EBICS. By acting as a single gateway to over 11,000 banks, SWIFTNet helps to simplify bank connectivity for companies that are willing to build a direct connection to SWIFT and pay the necessary fees.

Once a SWIFT connection is in place, it can help companies change banking partners and expand internationally more easily. It may also be well-suited for companies looking to connect to a large number of their secondary banks that see relatively low transaction volume.

The volume aspect is key because SWIFT charges a per-message fee, potentially leading to high costs with more usage. Combined with ongoing membership fees and infrastructure costs, it can be expensive to maintain a direct SWIFT connection – especially for banks that see a high level of activity.

Building a direct connection to SWIFT in the first place can also be costly and time-consuming, requiring considerable engineering resources and know-how. Plus, you need to comply fully with SWIFT’s security policies. Most companies that use SWIFT therefore connect via a third-party provider, such as their bank or a service bureau, to whom they effectively outsource their bank connectivity.

• Pros: A single connectivity gateway to thousands of banks, with robust security and high reliability, that may prove useful in connecting to a large number of lower-tier banks.
• Cons: A direct integration can be costly to implement and maintain, plus there are fees associated with using the network.

‍

Corporate banking APIs

An API (Application Programming Interface) enables two pieces of software to communicate with one another. More and more banks have begun to offer proprietary APIs that provide companies with programmatic, real-time access to their banking services. These ‘premium’ APIs are distinct from open banking or PSD2 APIs in that banks typically charge companies a fee in order to use them and they are designed to support complex financial and treasury operations.

How corporate banking APIs work

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.

While the APIs offered by banks do not adhere to a single standard, they frequently use ISO 20022 for message exchanges. Depending on the maturity of the API and the quality of the bank’s documentation, a connection can be built and tested with minimal coordination work needed with the bank, allowing for faster onboarding and implementation.

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.

Pros and cons of corporate banking APIs

Integrating with and maintaining an API connection requires engineering expertise, but the process can be quick if the API is well-documented. The key benefit is that APIs enable companies to manage their finances in real time as opposed to accessing data that is 24 or 48 hours old. This can drive major improvements in short-term cash management, the quality of financial insights, and general team and process efficiency.

APIs are potentially a game-changer for bank connectivity – as long as the bank can guarantee its reliability. The risk of relying on APIs alone is that some banks do not support or maintain them well enough, if at all, leading to issues with downtime as well as missing data. When it comes to something as critical as treasury management, these kinds of reliability issues can be damaging.

Nonetheless, as API quality improves, the ability to support them will increasingly be a key consideration for companies choosing a new bank or treasury system. A key benefit of modern treasury platforms like Atlar is that they support API connectivity alongside established methods such as H2H, giving companies the best of both worlds.

• Pros: Corporate banking APIs can be easier to integrate with and help unlock real-time balance data, faster payments, live tracking, and up-to-date reports among other benefits.
• Cons: API maturity varies across banks and many do not maintain them well enough for corporate use cases yet (if they offer an API at all).

‍

Open banking

Open banking started to take off in Europe after the Payment Services Directive (PSD2) came into force in 2016. PSD2 introduced rules that obliged banks to give licensed third parties access to their customers’ payment and account data, provided that the customer gave their consent.

Unlike corporate banking APIs, which are designed specifically for business customers, open banking APIs are predominantly used today for consumer use cases including budgeting apps, loan applications, and account verification.

How open banking works

Here’s a brief run-down of how open banking works:

• Consent: The customer provides consent to a third-party provider to access their banking data.
• Authentication: The customer is authenticated using secure methods such as multi-factor authentication (MFA), specifically Strong Customer Authentication (SCA) in Europe.
• API request: The third-party provider sends a request to the bank's API to access specific banking data or initiate a payment and the bank processes the request.
• Service provision: The accessed data is used by the third party to provide a service, such as aggregating account information from multiple banks or initiating a payment.

Pros and cons of open banking

Open banking regulations like PSD2 require banks to meet certain API standards, but much still depends on the individual banks. The availability of open banking APIs is patchy in some countries and, when they are available, there are often reliability issues. Banks in the UK and Nordic countries tend to offer more mature APIs than those elsewhere.

Since banks cannot monetize open banking APIs – in the EU, they must be provided free of charge – these APIs are often less well-maintained and less complete than the banks’ corporate APIs. For instance, not all types of business accounts or financial data may be accessible if they are not mandated by regulations like PSD2. Additionally, in Europe, you need to complete an SCA step for every payment and at least every 90 days to access account information. This can disrupt your company’s payment approval process and create a significant operational risk.

Because of these reasons, it’s fair to say that open banking is yet to be seen as a serious alternative by most treasury professionals. Nonetheless, it may be a viable option for companies with straightforward use cases, such as reading balances for a small number of accounts. The implementation can potentially be very quick if your chosen provider has already connected to a bank’s open banking API.

In sum, open banking could be an attractive, cost-effective option for smaller businesses (with fewer than 100 employees) looking for simple cash reporting and planning tools. For businesses with more advanced use cases, open banking is unlikely to provide the required level of reliability and data quality.

• Pros: Depending on the banks and the quality of their APIs, open banking can be an option for smaller businesses that don’t require the full breadth of financial data or payment capabilities.
• Cons: Open banking is effectively limited to Europe and the US, and many banks in Europe have yet to provide a functional API. It is unlikely to offer the reliability and data quality needed by dedicated treasury teams.

‍

How Atlar can help with your bank connectivity

Bank connectivity is non-negotiable for most companies with any level of financial complexity. It unlocks the ability to automate payments, cash reporting, reconciliation, and much more. 

By integrating bank data into a single platform, you no longer need to log into bank portals individually and can leave manual data entry behind. More than that, though, it ultimately enables you to manage your company’s cash more efficiently and use it optimally: forecast future cash needs, optimize liquidity, and identify excess cash that can be invested.

H2H, EBICS, SWIFT, and APIs – different banks specialize in different connectivity options. As a company grows, it pays to use a platform that can connect to all of them. Generally, H2H methods like SFTP provide the most reliable, high-quality data transfer today but some banks and many PSPs already offer robust, real-time APIs. What’s key is having the ability to connect to any bank using the best method available.

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.