There is no universal point at which a company “graduates” to its own connected BIC. A business with hundreds of bank accounts may still be well served by managed connectivity, while another with fewer accounts may have a stronger case because it wants more control over its identity, provider relationships and long-term connectivity architecture.
The distinction matters because a BIC, SWIFT access and the infrastructure used to connect to SWIFT are not the same thing. SWIFT defines connected BICs as BICs with access to the SWIFT network, while non-connected BICs can still be used for identification. SWIFT also supports indirect or shared connectivity through service bureaux, so having your own connected BIC does not necessarily mean operating the technical infrastructure yourself.
The decision is therefore not primarily about size. It is about whether owning the identity layer creates a strategic benefit that outweighs the additional governance and responsibility. These seven signs suggest it may be worth evaluating.
About the author
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.
1. You want your connectivity identity to outlive your provider
One of the strongest reasons to consider an own connected BIC is portability.
Treasury providers, service bureaux, banks and technology platforms can change. Your corporate identity does not have to change with them.
If a company expects its bank-connectivity architecture to evolve over many years, having its own connected BIC can create a clearer separation between who the corporate is on the network and who currently provides the infrastructure used to reach it.
That does not eliminate migration work. Banks still need to be coordinated, technical configurations may change and testing remains necessary. But it can reduce the extent to which the company's SWIFT identity is tied to one particular provider setup.
The relevant question is therefore not “Do we want to operate SWIFT ourselves?” It is: Do we want our identity to remain ours when the operating model changes?
2. Provider portability has become strategically important
Most companies do not need to design treasury infrastructure around the theoretical possibility of changing providers. At some point, however, that flexibility can become valuable.
A large international group may expect acquisitions, divestments, treasury-system changes or changes in outsourcing strategy. It may also simply want to avoid a future architecture in which changing the connectivity provider means reconsidering the corporate's identity and bank setup at the same time.
An own connected BIC can help separate those decisions.
This is not the same as eliminating provider dependency. The company may still depend heavily on a service bureau or connectivity platform for technical operations. SWIFT explicitly supports indirect and shared connectivity models through service bureaux.
The advantage is more specific: the provider can change without necessarily redefining the corporate identity at the centre of the model.
That is a much stronger reason than simply saying the company is large or internationally complex.
3. You know exactly which layer you want to own
“More control” is often used to justify an own BIC, but it is too vague to make a good business case.
There are several layers in a multi-bank architecture: corporate identity, SWIFT access, connectivity infrastructure, message transformation, ERP or TMS integration, bank onboarding and day-to-day support.
A company does not have to own all of them.
It may want its own connected BIC while outsourcing the technical connection to a service bureau. It may retain control over bank relationships and message standards while relying on a provider for monitoring and infrastructure. Or it may choose a largely managed model while keeping architectural decision-making internally.
This is where mature organisations differ from merely ambitious ones. They do not ask whether they should “own SWIFT”. They decide deliberately which responsibilities create strategic value when retained and which are better delegated.
If that distinction is already clear internally, an own connected BIC becomes a much more credible option.
4. Your target architecture is stable enough to justify a long-term identity
An own connected BIC makes more sense when it sits inside a defined treasury architecture rather than being used to solve a temporary connectivity problem.
That usually means the company has a reasonably clear view of how ERPs, TMS platforms, payment factories, banks and connectivity providers should interact over the coming years.
This does not mean the architecture will never change. Quite the opposite: the value of a stable identity can become greater when the surrounding environment changes frequently.
But there should be a stable centre.
If the company is simultaneously replacing its ERP, reconsidering its TMS, rationalising banks and redesigning payment processes, adding another ownership decision may create more complexity than flexibility.
An own BIC is strongest when it anchors an architecture. It is much weaker when it is expected to compensate for the absence of one.
5. A group-level identity creates a real operational benefit
Payment factories and central treasury operations are often cited as obvious reasons for an own connected BIC. They can be, but centralisation alone is not enough.
The important question is what a group-level identity actually changes.
For example, it may support a model in which the corporate wants a consistent SWIFT identity across multiple banking relationships while keeping individual bank connections and infrastructure providers replaceable. It may also fit a treasury architecture in which communication is deliberately centralised at group level rather than organised around individual subsidiaries or banks.
The BIC does not create the payment factory. It does not standardise pain.001 messages, rationalise bank accounts or fix fragmented approval processes. Those remain separate pieces of work.
Its value is narrower but potentially important: it can provide a stable identity around which that central model is organised.
That is a better reason for having one than simply saying, “We run a lot of payments.”
6. Governance responsibilities are deliberately divided
An own connected BIC should not be confused with a decision to bring every technical responsibility in-house.
SWIFT allows users to connect indirectly or through shared infrastructure, including service bureaux operating under its Shared Infrastructure Programme. That means the practical responsibilities can look very different depending on the architecture.
What matters is that the company knows where each responsibility sits.
Who owns the SWIFT relationship? Who controls access and approvals? Who manages the technical infrastructure? Who monitors the connection? Who handles certificates and security controls where relevant? Who coordinates a new bank? And who takes the lead when a critical payment fails close to cut-off?
The answer may involve treasury, IT, information security, the connectivity provider and the bank.
The important thing is not that the corporate performs every task itself. It is that responsibility does not disappear into the gaps between those parties.
An own connected BIC becomes much more sensible when that operating model already exists on paper and in practice.
7. The economics of independence hold up over time
An own connected BIC should ultimately have an economic rationale, even if the benefit is not simply a reduction in annual fees.
The business case should examine what the company gains from keeping the identity layer under its own control. Does it lower future switching costs? Improve provider portability? Support a long-term centralisation strategy? Reduce dependence on a particular architecture? Create useful flexibility during acquisitions or major systems changes?
Those benefits need to be weighed against the full cost of the model: implementation, provider charges, internal expertise, governance, testing, operational support and future change.
A five-year view is often more useful than a one-year comparison because the value of portability rarely appears on day one.
Pressure-test the model as well. What happens if the company changes its connectivity provider? Replaces its TMS? Acquires a large group with different banks? Changes its outsourcing strategy?
If the own-BIC model makes those scenarios materially easier or less risky, there may be a genuine strategic case. If nothing meaningful changes, ownership may be solving a problem the company does not have.
The strongest case is not size. It is optionality.
The case for an own connected BIC is often framed around maturity: large companies eventually reach a point where they should own more of their connectivity.
That is too simplistic.
A sophisticated treasury does not necessarily own more infrastructure. It understands which parts of the architecture should remain under corporate control and which can be operated more effectively by specialists.
For some companies, the connected BIC becomes valuable because it establishes a corporate identity that can persist while banks, platforms and connectivity providers change around it. For others, that degree of separation creates little practical benefit, and a managed model remains entirely rational.
The real question is therefore not: “Are we big enough for our own BIC?”
It is: “Would owning this layer give us enough portability, control or long-term flexibility to justify it?”
If the answer is clear, an own connected BIC may deserve serious consideration. If the answer is vague, the organisation probably has more important connectivity questions to solve first.
About Cobase
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.
