Simple Object Access Protocol (SOAP)

Introduction to SOAP

SOAP (Simple Object Access Protocol) is a messaging protocol that enables structured data exchange between systems using XML. In the context of bank connectivity, SOAP is used by some banks as the underlying protocol for their web services, allowing companies to send payment instructions and retrieve account data programmatically.

‍

SOAP-based connections are a variant of host-to-host connectivity. Rather than exchanging flat files over SFTP, a company's ERP or treasury management system (TMS) communicates with the bank's server through structured XML messages sent over HTTPS. SOAP has been widely adopted in enterprise banking environments, particularly by banks that built their digital infrastructure before modern REST APIs became prevalent.

How SOAP works

SOAP defines a standardized format for messages exchanged between a client (the company's system) and a server (the bank). Each message is wrapped in an XML envelope that contains a header and a body. The header carries metadata such as authentication credentials and security tokens, while the body contains the actual request or response data – for example, a payment instruction or an account balance query.

‍

A key feature of SOAP is its use of WSDL (Web Services Description Language), a formal contract that defines the operations a bank's web service supports, the expected input and output formats, and how to access the service. This contract-driven approach means that both parties know exactly what data to send and expect in return, reducing the risk of integration errors.

‍

SOAP typically runs over HTTPS, though it can also operate over other protocols such as SMTP. For security, many banking SOAP implementations use WS-Security, which provides message-level encryption and digital signatures. This means the content of each message remains protected even after it passes through intermediary systems – an advantage over transport-level security alone.

Pros and cons of SOAP

• Pros: SOAP provides strong, built-in security through WS-Security, which is well suited to sensitive financial data. Its formal WSDL contracts enforce strict data validation, reducing the chance of malformed messages. SOAP also supports complex operations such as multi-step transactions, making it reliable for use cases like payment processing where each message must be handled exactly once.

• Cons: SOAP messages are verbose due to the XML envelope structure, resulting in larger payloads and slower processing compared to lighter protocols. Implementing and maintaining SOAP integrations requires significant technical expertise and the rigid format offers less flexibility than modern REST-based APIs. As a result, most banks that are building new connectivity services today favour REST APIs over SOAP, though many legacy SOAP interfaces remain in active use.

How Atlar can help with bank connectivity

Atlar supports a range of connectivity methods – including SFTP, EBICS, SWIFT, and real-time APIs – and manages all implementation work on behalf of its customers. With prebuilt connections to over sixty major banks globally, Atlar handles the complexity of different protocols and formats so companies don't have to. Atlar customers are up and running with all their banks connected in 2–3 months on average, compared to 6–18 months for a traditional TMS. To learn more, get in touch with our team.