The 5 most common bank connectivity channels

One of the most important processes for companies whose business involves managing large volumes of payments is to automate such flows.

It starts with generating payment files (for instance ISO 20022 XML files for SEPA payments). Companies frequently rely on third-party software like enterprise resource planning systems (ERP) or treasury management systems (TMS) to generate such files.

After completing this step, the next step is to transmit those files to the bank, which can take two forms:

1. Upload them into a web banking system. It means connecting to your bank’s web application, going to the file import section, uploading your file, signing it, and waiting for it to be processed. This first option is a good fit if you only have to manage a couple of payments from time to time while ensuring a high level of control.

2. Directly connect to your bank’s cash management infrastructure via a server connection. This method is preferred for automation purposes. This option is a powerful alternative for medium to large-scale businesses and fintech companies that have large payment flows directly linked to their core business.

Let’s take a closer look at the most common connectivity channels that banks provide to their customers in order to transmit payment instructions and retrieve back reporting files.

1. SFTP

SFTP (Secure File Transfer Protocol, also known as “host-to-host”) is a network protocol meant to securely transmit and manage files on a remote server. It essentially is a shared folder in the cloud accessible by a customer and its bank. Banks provide such access to exchange payment instructions and make reporting files available to their customers.

The connexion is generally based on SSH keys to secure the exchanges and files are usually signed and encrypted using PGP keys.

2. EBICS

EBICS (for Electronic Banking Internet Communication Standard) is a banking protocol developed in Germany by the Zentraler Kreditausschuss (ZKA) in 2008 and later adopted in France by the Comité Français d’Organisation et de Normalisation Bancaire (CFONB). Since its launch, this protocol has been adopted by most banks in France, Germany, Austria, Switzerland, and Portugal. EBICS 2.4 has been used by the French bank community while EBICS 2.5 is used by Germany and Switzerland. Their successor EBICS 3.0 launched in 2018 will ultimately replace local implementations of this protocol.

Files transmission is secured by HTTPS (TLS) and files are signed and encrypted using X.509 certificates. There are two types of EBICS: EBICS T (for Transport) which requires a user to validate the payment file in the bank’s web banking app; and its successor EBICS TS (Transport + Signature) which requires the user to electronically sign the payment file with an external device (whether a Swift 3SKey or certificates). While both options are highly secured, they often get in the way of payment automation.

3. SwiftNet

Swift’s proprietary payment network SwiftNet is often proposed by banks to transmit local and international payment instructions. Customers can submit their payment files, often formatted as ISO 20022 XML files, Swift MT files, or local payment messages such as CFONB. Finally, just like with EBICS, customers have to electronically sign these messages before being processed by the bank using Swift’s 3SKey physical devices.

4. APIs

To satisfy customers with an increased appetite for instant payments and real-time notifications, banks have started to widely develop APIs as new connectivity channels. Bank APIs are mostly addressed to regulated PSD2 service providers, such as Account Information Services Providers (AISP) and Payment Information Services Providers (PISP). Still, some banks also provide direct corporate APIs to their customers.

These APIs are usually based on REST principles, use JSON or raw XML formats, and leverage messages close to the ISO 20022 standard. They are served under HTTPS, are secured by the OAuth2 standard, and sometimes use SSL/mTLS and eIDAS certificates for encryption and signature.

5. Message brokers

As an alternative to APIs, some banks provide message brokers to transmit payment instructions in real-time. Banks frequently use off-the-shelf, enterprise-grade message broker solutions, as they require secure, scalable, and battle-tested infrastructures. This kind of system is oftentimes used by regulated financial institutions to exchange instant payment messages with clearing and settlement mechanisms (CSMs) through their sponsor bank.

The connectivity is often secured by dedicated VPN connections and certificates.

Connecting to banks in practice

Banks offer businesses and regulated financial institutions a wide range of connectivity solutions to get access to their cash management infrastructures. While those connectivity channels enable such customers to automate their payment operations, making sure that everything is configured correctly, secure, and encrypted can be challenging.

Numeral provides a single API that connects all payment methods and banks across Europe. It abstracts all payment files, messages, security mechanisms, and connectivity channels into a unified and secure API.