By Topias Vainio, Treasury Solutions Manager at FinanceKey 

“If we connect to a bank via an API, is Swift still involved somewhere in the background?” 

That was one of the questions I received while presenting use cases around real-time banking data at a treasury conference recently. It shows how bank connectivity is still an evolving topic for many treasury teams. 

For decades, corporates have relied on direct host-to-host (H2H) connections as well as the global Swift network. These methods are well-established and reliable, but they deliver data in batches. Most end-of-day statements are generated overnight, and intraday updates depend on each bank’s schedule. 

Now, APIs are entering the picture, enabling real-time visibility into balances and transactions – and in some cases, delivering statements in CAMT format. 

In this article, I’ll walk through the main connectivity options – from the legacy methods that have shaped treasury for decades to the API-based approaches now gaining traction as treasuries move toward real-time operations. 

H2H (host-to-host): traditional and trusted 

H2H refers to a direct connection between a company’s system and its banks, typically used to exchange payment files and reporting data. These connections can take different forms – from simple file transfers using SFTP (Secure File Transfer Protocol) to more standardised frameworks like EBICS and Web Services. 

All three are file-based at their core, but EBICS and Web Services go further by adding structure, authentication, and security layers on top of basic file transfer. 

EBICS: regional H2H standard 

EBICS (Electronic Banking Internet Communication Standard) is a standardised H2H protocol primarily used in Germany, France, Austria, and Switzerland. It supports multiple message types – for example, PAIN files for payment initiation and CAMT files for bank statements – and enables secure, multi-bank communication through a common format. 

Web Services: structured and widely supported 

Web Services are another form of H2H connectivity. They use a structured messaging framework, most commonly SOAP (Simple Object Access Protocol), to exchange account and transaction information between treasury systems and banks. Think of it as a digital “envelope” that wraps around financial data, ensuring messages are sent and received in a consistent format with robust security. 

For treasurers, both EBICS and Web Services offer predictability and reliability – qualities that have made them trusted, long-standing standards for file-based communication.

What they lack, however, is immediacy: updates typically follow bank-defined schedules rather than real-time triggers. 

Swift: the global network and messaging standard 

Swift is the world’s most established financial messaging network, connecting more than 11,000 banks globally. 

Pros 

• Global reach and standardisation 
• Secure, proven infrastructure 
• Option for interim transaction reports (MT942) 

Cons 

• Can be costly to maintain for corporates 
• Time-intensive to implement 
• Intra-day reports are scheduled, not on demand 

For financial institutions and multinational treasuries, Swift remains indispensable for consistent reporting across a wide range of banks. But implementations can be heavy and the setup less adaptable, with multiple parties involved – including service bureaus. That’s why many corporates now complement Swift with APIs to gain flexibility and real-time connectivity. 

APIs: the future of connectivity 

APIs (application programming interfaces) are transforming bank reporting by enabling real-time, direct access to account balances and transactions. Some banks also provide APIs to query historical statements from a specific date. 

There are two main types of APIs in this context: 

• Open banking APIs: regulation-driven, low-cost, and widely available in the EU, with similar frameworks now in place or being developed in other markets. 
• Premium (or corporate) APIs: direct bank connectivity designed for enterprise scale, often with richer and more detailed data supporting reconciliation and reporting needs. 

For more on this, read our article on the differences between open banking and premium APIs. 

On the payment side, API adoption is still maturing. Not all payment types are supported (for example, salary payments), and PSD2-regulated APIs often require approvals – whereas file-based channels with auto-approvals better fit corporate needs today. 

However, payment tracking and beneficiary validation APIs already offer clear advantages over traditional file-based channels. 

The rise in APIs marks a clear shift toward real-time treasury – where information flows continuously rather than in batches. Adoption rates vary across banks and regions, but momentum is clear: more corporates are using APIs for reporting every year as banks expand their capabilities and standardisation efforts progress. 

Making the right choice 

Connectivity is not about picking one method over another. The right choice depends on your geographical footprint and use case.  

Large corporations often rely on Swift for global reach, while mid-size and smaller businesses typically use H2H connections. For truly global operations with dozens of banks across jurisdictions, Swift is often the practical option – but APIs are becoming the preferred choice for speed of implementation and real-time visibility across all company sizes. 

The right approach also depends on your banking partners, systems, and business needs. For example, a company aiming to reduce idle cash would benefit from near real-time visibility, allowing funds to be moved before payment cut-offs. 

For reporting, APIs are already delivering real-time value for FinanceKey customers. They enable balances and transactions to be accessed directly – a step change from older batch-based methods like H2H or Swift, where updates only arrive on a fixed schedule. 

Payments, however, are a different story. API adoption there is still emerging, and for most banks, file-based methods remain the most reliable choice. That’s why treasuries today can’t rely on just one channel – they need a hybrid connectivity strategy that brings together the best of both worlds: APIs for real-time reporting and established methods for payments until API coverage matures further. 

When data needs to be pushed in a traditional statement format (such as CAMT) to downstream systems, API data may require conversion into a file.

This is where providers like FinanceKey help businesses transition step by step, supporting hybrid connectivity as the world moves from file-based batch processing to API-driven operations. 

Our platform: 

• Standardises data so it flows cleanly into ERP and TMS systems 
• Orchestrates connections across multiple banks and geographies 
• Manages consents and certificates to ensure secure, uninterrupted API access 
• Monitors data quality to detect gaps, errors, or duplicates before they reach downstream systems 

This foundation allows treasuries to benefit from real-time APIs without managing the underlying complexity themselves – combining the reliability of legacy methods with the agility of modern connectivity. 

This is what our customer NORS has done: executing sweeps for excess cash with MT101 messages via Swift, triggered by real-time balance updates via APIs. 

At FinanceKey, we’ve built the capability to support hybrid connectivity – across both APIs and file-based channels – helping treasuries move toward real-time finance operations and future-proof their bank connectivity landscape. 

So, is Swift still involved in the background when it comes to APIs? It depends. 

Swift is developing a Swift Account Reporting API as part of its API standardisation programme, accessible via the Swift API Gateway. At the same time, banks are innovating with their own APIs, which may or may not follow Swift’s standards. In those cases, Swift isn’t involved in the background. 

If you’re exploring how to modernise your payment and treasury setup, or looking to start using APIs for specific use cases, contact us to find out more.