When treasury starts discussing SWIFT, one question often appears surprisingly early: Do we need our own BIC? It sounds like the right place to start. Often, it is not.
The problem is that a BIC and SWIFT connectivity are easily collapsed into the same decision. They are related, but they answer different questions. A BIC identifies an organisation. It does not, by itself, determine how that organisation connects to banks, who operates the infrastructure, how messages move between systems or who supports the setup when something goes wrong.
That distinction matters because companies can otherwise end up solving the wrong problem. If treasury wants fewer bank portals, automated statements, central payment initiation or better visibility across banks, the real issue is connectivity and integration. If the objective is to create a corporate identity that remains independent of a particular provider or banking relationship, then an own connected BIC becomes a more relevant part of the discussion. Those are very different ambitions.
Matthias Varenkamp is Head of Corporate Sales at Cobase. He has been with Cobase for more than six years, working with international companies on complex treasury and banking environments. His focus is on helping organisations simplify multi-bank connectivity, SWIFT and payment infrastructure, and turn fragmented banking setups into scalable operating models. In this series, he shares the practical patterns, challenges and lessons he sees across the market.
A BIC, or Business Identifier Code, is a recognised identifier used across financial messaging and reference data. It can identify a bank, financial institution, corporate or other eligible organisation. But having a BIC does not automatically mean being connected to the SWIFT network.
A non-connected BIC can be used purely for identification. A connected BIC is associated with an organisation that has access to the SWIFT network, but even then the BIC itself is not the connectivity infrastructure. That infrastructure can still be operated in different ways. A corporate may run more of the environment itself, rely on a specialist provider, or use a model somewhere between the two.
This is why the phrase “our own SWIFT connection” can be misleading. It can refer to identity, network participation, technical infrastructure, operational responsibility or all of them at once. Treasury needs to know which one it actually means.
SWIFT connectivity is better understood as a stack. There is the identity used within the financial messaging ecosystem, access to the network, the technical route between an ERP, TMS or payment platform and that network, bank onboarding, message configuration and testing, and the operational work that follows after go-live.
A corporate can own some of these layers and outsource others. One company may decide that keeping its own identity is strategically valuable because it wants greater portability between providers over time. Another may care much less about the identity layer and focus instead on dependable access to many banks through one consistent operating model. Both can be sophisticated treasury organisations. They are simply solving different problems.
SWIFT can provide a common route into multiple banks, but it does not make those banks behave identically. Banks can still differ in payment formats, implementation guidance, testing procedures, reporting options, cut-off times and acknowledgement behaviour. A pain.001 accepted by one bank may still require different data or configuration for another.
That matters because one of the implicit attractions of an own connected BIC can be the idea that it removes bank-by-bank complexity. It does not. What it can do is provide a more stable foundation around which that complexity is managed. The corporate may be able to keep its identity and high-level architecture consistent even as individual banking relationships change.
The same applies to change more broadly. A connection can remain technically available while the environment around it evolves. Banks update implementation guidance, ISO 20022 usage changes, ERP mappings are amended, new entities are added and treasury processes are redesigned. The network can keep working throughout all of this.
So technical connectivity is only one part of the picture. The real challenge is keeping the overall model aligned with changing business processes, data and banking relationships.
There is also a tendency to treat an own connected BIC as a milestone. Treasury moves from portals to host-to-host, from bilateral connections to SWIFT, and eventually reaches the supposedly more mature state of owning its own identity.
That is the wrong way to think about it.
Treasury maturity is better measured by the quality of the operating model than by how much infrastructure the company owns. A treasury function with clean payment processes, strong controls, consistent data, reliable integrations and clear responsibilities can be highly mature while using managed connectivity. Equally, an organisation can own more of its SWIFT setup and still suffer from fragmented processes, unclear support responsibilities and inconsistent bank onboarding.
Ownership is not maturity. It is an architectural choice.
The business case for an own connected BIC is often framed around “greater control” or “greater independence”. Both can be valid arguments, but only if they are made specific. Control over what? The corporate identity, choice of connectivity provider, bank onboarding, message routing, security or operational support? Independence from whom? A bank, a service bureau, a technology platform or internal IT?
These distinctions matter. An own connected BIC may give a corporate more separation between its identity and the provider operating the connectivity. That can be valuable if provider portability is part of the long-term strategy. But it does not automatically make the company independent of providers, banks or specialist technical expertise.
The value therefore lies less in “owning SWIFT” and more in deciding which dependencies the company deliberately wants to retain and which it wants to reduce.
The most useful question is not “Do we need our own BIC?” It is: what do we want to remain stable when banks, systems and providers change?
For some companies, the answer will include their own connected BIC. A persistent corporate identity may support a long-term architecture in which banks or connectivity providers can change without redefining the centre of the model.
For others, that creates little practical advantage. Their priority may be reliable payment initiation, automated reporting, broad bank reach and a support model that works. Those outcomes do not automatically require ownership of the BIC.
That is why the decision should follow the architecture rather than lead it.
A BIC answers an important question: who are we in the financial messaging ecosystem? It does not, by itself, answer the more difficult one: how should we connect?
Cobase supports corporates with bank connectivity across SWIFT, host-to-host (SFTP), EBICS and bank APIs, allowing different channels to be combined within one connectivity model. As a SWIFT Business Connect provider, Cobase can also support companies that want to retain their own SWIFT identity, including the onboarding or migration of an existing BIC to SWIFT Alliance Cloud. This gives treasury teams the flexibility to choose the connectivity model that best fits their banking landscape without having to operate every part of the infrastructure themselves.