Treasury connectivity in flux

Corporate Treasury increasingly faces the challenge of further automating payments, liquidity management, risk management and reporting while responding more quickly to changes in markets and liquidity. Real-time information on account balances, payment status, liquidity positions and risk exposures is evolving from a convenient feature into an operational requirement for reliable Treasury management.

Established communication channels such as EBICS, SWIFT and host-to-host connections have been in use for many years and remain indispensable to numerous Corporate Treasury processes. However, they reach their limits where high flexibility, rapid response times and near-real-time communication are required.

Against this backdrop, application programming interfaces, or APIs, continue to gain considerable importance. APIs are not an entirely new technology. They have been used in system integration for many years. What has changed, however, is their maturity in the corporate banking and Treasury environment. Banks are increasingly investing in their own API platforms and developer portals, offering standardized, documented and production-ready services. At the same time, Treasury and ERP systems are increasingly providing APIs as a standard component of their integration architecture. Treasury professionals must therefore consider the role APIs play in their organizations today and in the future, as well as how APIs can complement or, in some cases, replace existing bank connectivity solutions.

This article outlines the relevant technological and regulatory foundations, examines typical use cases, security considerations and tangible benefits and uses an SAP-based example to illustrate what API-enabled bank connectivity can look like in practice.

APIs should therefore not be viewed merely as a new technical channel for connecting to banks. Their real value lies in enabling Treasury processes to become more real-time, more data-driven and more integrated.

An application programming interface (API) is a standardized interface that allows two systems to exchange information automatically and in a structured format. Unlike traditional file-based exchanges, in which payment or account information is bundled into files, stored on servers and subsequently transmitted, an API enables a direct, transaction-specific exchange of data between a Treasury system and a bank, often in near real time. APIs connecting Treasury systems with market data providers or payment service providers are also becoming increasingly important.

In a Treasury context, APIs can be used in particular for the following activities:

• Retrieving account balances and intraday information
• Retrieving bank statements
• Checking the payment status of individual transactions
• Submitting payments and payment files, including instant payments
• Validating beneficiaries or account details
• Integrating payment service providers and platforms
• Retrieving foreign exchange rates and other market data
• Providing bank reports and fee overviews.

APIs are not entering an empty field. Rather, they complement an established landscape of technical interfaces in Treasury. One of the most widely used methods is EBICS, which is prevalent across Europe and primarily used to exchange payment files and account statements. Data is transferred in files, typically according to defined processing cycles.

In an international context, the SWIFT network often plays a central role. It enables standardized communication with a large number of banks worldwide, providing extensive reach as well as established security and governance standards.

Many companies also use host-to-host connections to exchange payment files, reports or account statements securely. Here, too, the focus is on file-based information transfer. Host-to-host connectivity via SFTP is comparatively straightforward to implement and is frequently used for bespoke bank connections or reporting scenarios.

APIs, by contrast, take a different approach. Instead of exchanging files, the Treasury system and the bank communicate directly through standardized service interfaces. This allows transaction-specific information to be made available in near real time. Examples include real-time account balance queries, payment status updates and the direct integration of bank services into Treasury and ERP systems.

APIs should therefore not be viewed primarily as a complete replacement for existing solutions. Instead, they expand Treasury connectivity to support new use cases in which speed, flexibility and immediate access to information are key.

Many banks now treat APIs as standalone channels, providing resources that make integration easier. Typical offerings include:

• Dedicated API portals with an overview of available services
• Detailed technical documentation and specifications
• Sandbox and test environments for experimentation without production risk
• Test access and sample data for development purposes

These features allow organizations to test integrations early, evaluate functionality, and assess implementation efforts before moving into production.

APIs have matured significantly. Nowadays, banks offer API portals, technical documentation, sandbox environments, and test access. This allows organizations to evaluate available services, assess reliability, and determine the required integration effort earlier.

Regulatory developments, such as PSD2, have accelerated the availability of secure interfaces in the banking sector. Although PSD2 was not specifically designed for traditional corporate treasury operations, it has contributed to standardizing API technology. Beyond regulatory APIs, corporate or premium APIs are emerging, offering enhanced data quality and operational stability aligned with business requirements.

Treasury teams benefit practically as information can be delivered more swiftly, reducing manual inquiries and supporting processes like liquidity management, payment status tracking, and reconciliation more efficiently.

APIs extend beyond bank connectivity to other treasury processes, such as retrieving foreign exchange rates, interest rate information and market data, integrating trading platforms for FX and money market transactions as well as connecting with payment service providers and platforms.

Additional uses include validating payment beneficiaries and account information, automatically offering data for cash forecasting, liquidity planning as well as integrating in-house banking, netting, or payment factory processes. APIs enable automation for internal payment and settlement processes in centralized treasury organizations by connecting internal accounts, intercompany positions, netting processes, payment factories and ERP postings.

Looking ahead, API-based data can be used for treasury dashboards, analytics and AI-supported insights. Thus, APIs are not merely additional banking channels but integration building blocks for a more connected treasury environment.

Economic considerations are increasingly important alongside functional requirements in evaluating modern bank connectivity solutions. API access is often provided without additional usage fees, unlike traditional solutions that may involve costs for networks or middleware components. However, direct usage costs alone don't paint a complete picture.

API-based connectivity requires investment in design, implementation, operations, and maintenance of integration architecture and may involve transaction-based fees. The economic value is driven by efficiency and automation benefits, reducing manual steps, shortening processing times, and making information available faster – which is invaluable in payment processing and liquidity management.

Organizations should evaluate API solutions holistically, considering implementation costs and long-term benefits related to automation, scalability and operational efficiency.

Regulatory developments like the European Payment Services Directive (PSD2 and PSD3; more information can be found at KPMG-Law) have driven API development in electronic payments. These regulations specify rules for banks, payment service providers, organizations and customers, regulating account information access and payment initiation by third parties. They require banks to provide secure interfaces, accelerating API connectivity development.

While these focus on retail, business accounts, and third-party services, and not corporate treasury operations, they have standardized API technology within the banking sector. This foundation supports broader treasury-focused APIs, extending beyond the original regulatory framework.

API communication, being direct and near real-time, requires heightened security and governance. Since APIs handle sensitive information, appropriate security is crucial, relying on robust authentication methods and end-to-end encryption. Typical risks include man-in-the-middle attacks from inadequately secured communication, misuse of API keys and tokens and errors from misconfiguration.

Treasury governance must ensure encryption standards, defined authorization and role concepts, comprehensive access logging, and compliance with internal control and regulatory requirements.

The SAP ecosystem is increasingly shifting towards an API-centric integration approach. SAP Business Technology Platform (SAP BTP) serves as a central integration layer, connecting banks through APIs and supporting processes through standardized interfaces. In the future, standard SAP Multi-Bank Connectivity (MBC) solutions may be complemented by BTP-based integration scenarios.

This trend isn't specific to SAP; specialized treasury management systems and other ERP platforms are adopting API-based approaches. Examples include:

• Treasury management systems such as TIS, Kyriba, ION WSS, FIS, among others
• ERP systems and payment hubs with integration and API layers

The move toward APIs affects many treasury systems, representing a broader evolution in bank connectivity rather than limited to a single vendor.

APIs are increasingly becoming key components of modern treasury architectures, enhancing established connectivity methods such as EBICS, SWIFT, or host-to-host connections by introducing new integration and communication capabilities. They offer flexibility and near real-time processing especially when quick information access and direct system-bank interaction are needed.

APIs enable reduced manual processing steps, lower operational effort, shorten payment operations times and increase transparency by providing bank information promptly and accurately. They simplify bank and service integration while laying technological foundations for future developments such as real-time treasury, embedded finance, and other digital banking services.

Treasury leaders should evaluate early how API connectivity can deliver functional or economic benefits, address regulatory and security requirements, and how APIs integrate into existing systems and governance landscapes. The aim is the strategic adoption of APIs for measurable improvements in efficiency, transparency, and control.