SAP Multi-Bank Connectivity (MBC): What It Is and Isn't

SAP Multi-Bank Connectivity (MBC) is a managed connectivity service that SAP runs on SAP Business Technology Platform (BTP). It carries payment files, payment status reports and bank statements between your SAP system and your banks, using whichever channel each bank supports: a direct link to a bank that has joined the network as a member, SFTP host-to-host, EBICS, or Swift. You connect SAP to it once, through the connector for SAP Multi-Bank Connectivity, and SAP operates the rest. MBC is a transport layer. It does not build your payment files, approve your payments, or change a single byte of what you send.

The last sentence matters, because most MBC disappointments come from expecting the service to do something it was never designed to do. This page covers what MBC is, how it compares with the connectivity options you already know, what flows through it, and what onboarding involves.

The three moving parts

An MBC landscape has three components, and SAP's Cloud FAQ (KBA 3398869) describes the tenant roles the same way:

SAP's documentation is explicit that all messages to and from MBC pass through the connector. That is also where you monitor them. Up to S/4HANA 1909 FP01 that meant the connector monitor, transaction /BSNAGT/MONITOR. From there on, and in S/4HANA Cloud Public Edition, it is the Fiori app Manage Bank Messages (F4385), where you can see failed messages, trigger reprocessing and download payloads.

How it differs from what you already know

MBC does not replace the four bank connectivity channels. It sits on top of them. What changes is who builds and runs each connection.

The Swift row needs one clarification. For Swift, SAP has acted as an Alliance Lite2 for Business Applications (L2BA) provider, a Swift partner model in which SAP operates the Swift infrastructure and integration for customers who hold their own Swift agreement. You still need that agreement, and you still have a relationship with Swift. SAP runs the plumbing. SAP also documents how the Swift Customer Security Programme applies in the MBC context. Read that page before assuming the attestation question has gone away.

"

MBC changes who runs the pipe. It does not change what flows through it: the file your bank rejects was built in your ERP, and that is where it gets fixed.

What flows through it

Outbound, MBC carries what your SAP system produces. That is typically pain.001 credit transfers built by the Payment Medium Workbench and a DMEE format tree, plus other payment files your banks accept. Inbound, it carries what the banks send back: pain.002 status reports and account reporting in camt.053, camt.052, camt.054, MT940, MT942 and BAI2. SAP's own guidance on common misconceptions is blunt on the key point: MBC does not change or transform file content. If a bank rejects a file for its structure, the fix is in the ERP's format configuration.

What happens to inbound messages depends on the process they belong to, and this is where MBC connects to the rest of the landscape:

• Payment status to BCM. When Bank Communication Management is used, BCM releases the approved batch to MBC. The status reports that come back update the batch, so the monitor shows what the bank actually did with it.
• Payment status to APM. In an Advanced Payment Management landscape, SAP documents inbound pain.002 processing through MBC into APM's own status handling.
• Bank statements to EBS. The connector documentation describes inbound statement payloads being handed to the standard import (FF.5), and SAP documents the import route as Import by Multi-Bank Connectivity. From there the posting rules and interpretation algorithms take over, as for any other statement source.

So the architecture is layered: APM decides what flows where, BCM decides whether it may leave, and MBC carries it. BCM, APM and output-management boundaries draws the same split from the control side.

Onboarding: what actually happens

MBC onboarding is partly a service request process, which is unfamiliar to teams used to building interfaces themselves. The outline, from SAP's own getting-started material:

1. Contract and tenants. MBC is licensed separately. SAP's Cloud documentation states that integration requires an active MBC license. SAP provisions test and production tenants and sends a welcome pack with a checklist.
2. Certificates. Each organization provides certificates signed by a certificate authority SAP trusts, one set per tenant. The SAP system also imports the root and intermediate certificates of the MBC endpoints in both test and production. Certificate expiry is an operational dependency from then on: put it in the interface monitoring calendar.
3. Connector configuration. On-premise, this is the connector add-on or S4CORE configuration plus the communication setup to the tenant. In Cloud Public Edition, it is the setup SAP documents under Integration with SAP Multi-Bank Connectivity.
4. Bank by bank. For SFTP, EBICS and member-bank connections, you raise a service request per bank. Each bank still has to agree the channel, exchange keys and run its own tests. MBC shortens the build, but it does not remove bank-side onboarding.
5. Formats and testing. Format content is agreed with each bank and built in the ERP. MBC carries the test files. It does not validate your pain.001 against the bank's implementation guide.

The realistic benefit is not that onboarding disappears. It is that bank number six uses the same connector, monitoring and security model as bank number one, instead of becoming a new integration project.

The Swift change on the horizon

Swift is retiring Alliance Lite2 for Business Applications, and the successor for embedded providers is Business Connect, which runs on Alliance Cloud. According to SAP's migration guide for MBC customers, the official L2BA end of life is December 2027, SAP's own deadline is 30 June 2027, and the migration is designed to change the engine underneath without format changes, a new MBC tenant or a reconfiguration of the S/4HANA system. If your MBC landscape uses Swift, put the migration window in the plan now and confirm the dates with SAP. Vendor deadlines move, and the review cycle on this page is set to catch that.

When I would choose it, and when I wouldn't

MBC makes the most sense when the landscape is SAP-centred, the bank count is more than a handful, and nobody wants to own a portfolio of per-bank SFTP and EBICS integrations. It also deserves the first look on S/4HANA Cloud Public Edition, where SAP documents MBC integration as part of the product's own bank integration setup.

It makes less sense when you already run a treasury middleware or a TMS that owns bank connectivity well, when one or two banks carry almost all the volume on a stable host-to-host link, or when most payments originate outside SAP. In those cases MBC adds a second connectivity estate rather than consolidating the first. The general trade-offs are on the integration patterns page. MBC is one concrete instance of the "managed network" option there.

What I couldn't verify, and left out

• Pricing and commercial model. Not documented publicly in a form I could cite.
• Which banks are member banks. The list changes and is SAP's to publish. Ask for it when you engage SAP rather than trusting a slide.
• API channels in detail. Some sources describe API-based bank connections through MBC. I could not confirm the scope and prerequisites in SAP's documentation, so they are not described here.

See also SAP payment approval workflow, EBICS and bank connectivity security.