In the sphere of core banking software, a key decision involves choosing the appropriate web service communication protocol. Today, we’ll discuss why RESTful APIs (Representational State Transfer) offer several advantages over SOAP APIs (Simple Object Access Protocol).
The choice of API standard determines how easily the core banking system can integrate with external services, how efficiently it handles concurrent requests, and how straightforwardly developers can build and maintain those integrations. RESTful APIs and SOAP APIs are two distinct approaches to API design, and the differences between them have practical implications for the performance, scalability, and maintainability of core banking software.
As illustrated in a typical RESTful API interaction within a core banking context, a payment initiation request is submitted by a client application as an HTTP POST request containing the payment details in JSON format. The core banking system processes the request, updates the relevant account records, routes the payment instruction to the appropriate payment rail, and returns an HTTP response containing the payment status in JSON format. The entire interaction is stateless, meaning the server does not retain any session information between requests, and each request contains all the information required for the server to process it independently. This stateless model is what enables RESTful APIs to scale horizontally across multiple server instances without requiring session synchronisation.
Key Takeaways: #
- RESTful APIs (Representational State Transfer) are the dominant API standard in modern core banking software, offering significant advantages over SOAP APIs (Simple Object Access Protocol) in terms of simplicity, performance, scalability, and compatibility with cloud-based and open banking infrastructure;
- The stateless architecture of RESTful APIs enables horizontal scaling and high concurrency, making them well suited to the transaction volumes and real-time processing requirements of payment institutions and e-money institutions;
- For payment institutions and e-money institutions subject to PSD2 open banking obligations, RESTful APIs are the standard format for open banking interfaces, as defined in the EBA RTS on SCA and secure communication and adopted by all major open banking frameworks including the UK Open Banking Standard and the Berlin Group NextGenPSD2 specification.
The Key Advantages of RESTful APIs Over SOAP APIs #
Simplicity and ease of development: RESTful APIs are built on standard HTTP methods, specifically GET for data retrieval, POST for data creation, PUT for data update, and DELETE for data removal. These methods are familiar to any developer with web development experience and map intuitively to common data operations. SOAP APIs, by contrast, require all operations to be expressed as XML-formatted messages within a defined envelope structure, with each operation described in a WSDL (Web Services Description Language) document. This additional layer of abstraction increases the complexity of SOAP API development, testing, and debugging, and extends the time required to onboard developers to a new integration.
Lightweight data format and network efficiency: RESTful APIs predominantly use JSON (JavaScript Object Notation) as their data format. JSON is a compact, human-readable format that represents data using key-value pairs and arrays, without the extensive markup required by XML. For equivalent data payloads, a JSON representation is consistently smaller than the corresponding XML representation, reducing the volume of data transmitted over the network for each API call. In a core banking environment processing high volumes of payment transactions, this reduction in payload size translates directly into lower network bandwidth consumption and faster response times across all API interactions.
Stateless architecture and horizontal scalability: Each RESTful API request is self-contained, carrying all the information required for the server to process it without reference to previous requests or stored session state. This stateless architecture allows the core banking system to distribute incoming API requests across multiple server instances without requiring those instances to share session data. As transaction volumes grow, additional server instances can be added to the pool without architectural changes, enabling the system to scale horizontally in response to demand. SOAP APIs do not preclude stateful implementations, but the additional complexity of managing state across distributed server instances makes horizontal scaling more challenging than in a RESTful architecture.
Compatibility and interoperability: RESTful APIs are language-agnostic and platform-independent, meaning they can be called by any client application capable of making HTTP requests, regardless of the programming language, framework, or operating system in use. This broad compatibility is a practical requirement for core banking software that must integrate with diverse external systems, including payment networks, open banking TPPs, card scheme APIs, and third-party compliance tools. SOAP APIs, while also interoperable in principle, impose more rigid structural requirements on client implementations and are less natively supported by modern web and mobile development frameworks.
Open banking and PSD2 compliance: The EBA RTS on SCA and secure communication, which defines the technical requirements for PSD2-compliant open banking APIs, specifies RESTful API architecture as the standard for open banking interfaces. The two principal open banking API specifications adopted across Europe, the Berlin Group NextGenPSD2 framework and the UK Open Banking Standard, are both RESTful implementations. Payment institutions and e-money institutions required to provide a PSD2-compliant open banking interface must therefore implement a RESTful API. A core banking system built on RESTful architecture is natively aligned with this requirement, whereas a SOAP-based system would require an additional translation layer to expose a compliant open banking interface.
HTTP caching for performance optimisation: RESTful APIs can leverage standard HTTP caching mechanisms, allowing frequently requested data to be served from cache rather than requiring the server to reprocess each request. HTTP caching is controlled through standardised headers that specify how long a response may be cached and under what conditions it must be revalidated. This caching capability reduces server load, improves response times for repeated requests, and lowers infrastructure costs for core banking operations with high read-to-write ratios, such as balance enquiries and account information requests. SOAP APIs do not natively support HTTP caching in the same way, as SOAP messages are typically transmitted via HTTP POST requests, which are not cacheable under standard HTTP caching rules.
Security and authentication standards: RESTful APIs use standard HTTPS for transport-layer encryption and support widely adopted authentication and authorisation frameworks including OAuth 2.0 and OpenID Connect. OAuth 2.0 is the authorisation framework specified in the EBA RTS for open banking API access, and is also widely used across payment network and third-party integration APIs. The combination of HTTPS and OAuth 2.0 provides a well-understood, extensively tested security model that is natively supported by most development frameworks and API management platforms. SOAP APIs implement security through the WS-Security standard, which provides equivalent security capabilities but requires additional configuration and is less natively supported in modern development tooling.
Developer productivity and ecosystem support: RESTful APIs are supported by a broad ecosystem of development tools, testing frameworks, API management platforms, and documentation standards. Tools such as OpenAPI (formerly Swagger) provide a standardised way to describe, document, and test RESTful APIs, reducing the time required to onboard developers and validate integrations. This ecosystem support accelerates development cycles, simplifies API maintenance, and makes it easier for payment institutions and e-money institutions to manage the growing number of API integrations that a modern core banking operation requires. SOAP APIs have a more limited tooling ecosystem in the modern development landscape, as investment in SOAP tooling has declined significantly as RESTful APIs have become the dominant standard.
When SOAP APIs May Still Be Relevant #
SOAP APIs retain relevance in specific contexts, particularly in integrations with legacy financial infrastructure where SOAP is the established standard. Some older payment network interfaces, interbank messaging systems, and enterprise software platforms continue to expose SOAP APIs, and institutions integrating with these systems must support SOAP regardless of their preferred API standard. In such cases, a core banking system with RESTful-first architecture can implement a SOAP adapter layer for legacy integrations while maintaining a RESTful architecture for all modern integrations.
FAQ: #
What is the difference between REST and RESTful?
- REST (Representational State Transfer) is an architectural style for distributed systems, defined by a set of constraints including statelessness, a uniform interface, and a client-server architecture. A RESTful API is an API that is implemented in accordance with these REST constraints. In practice, the terms REST and RESTful are used interchangeably to describe APIs that use HTTP methods and standard web formats such as JSON to enable communication between systems. An API that uses HTTP but does not conform to all REST constraints is sometimes described as REST-like or HTTP-based rather than strictly RESTful.
What is the Berlin Group NextGenPSD2 specification, and how does it relate to RESTful APIs?
- The Berlin Group NextGenPSD2 specification is a pan-European open banking API standard developed by the Berlin Group, a European payments interoperability initiative. It defines a common RESTful API framework that ASPSPs can implement to provide PSD2-compliant open banking interfaces to authorised TPPs, covering account information services and payment initiation services. The specification is widely adopted across EU member states as the basis for PSD2 open banking API implementation, alongside national variants defined by individual open banking schemes. For payment institutions and e-money institutions implementing open banking interfaces, alignment with the NextGenPSD2 specification ensures interoperability with TPPs that have built their integrations to this standard.
RESTful APIs promote a more developer-friendly approach by embracing web standards and leveraging familiar technologies. This facilitates easier adoption, integration, and collaboration among developers, expediting development cycles and fostering innovation.
While SOAP APIs may have their specific advantages in certain contexts, it’s clear that the RESTful API advantages, ranging from simplicity to scalability to security, make it a popular choice for modern, efficient, and scalable core banking software. The final choice between RESTful and SOAP APIs should always consider the specific requirements of your project, but understanding these advantages is critical to making an informed decision.
