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.
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 cannot explain what the BIC itself would change
Ask one simple question: What becomes possible after we have our own BIC that is not possible today? If the answer is better cash visibility, automated statements, fewer portals or centralised payments, keep digging.
Those outcomes depend on connectivity, integration, formats and processes. A BIC alone delivers none of them. If the business case cannot separate the identifier from the infrastructure around it, it is probably too early.
2. You are confusing identity with connectivity
Treasury often bundles several decisions together: Who identifies us in the network? How do we connect? Who operates that connectivity?
These do not need to have the same answer. A company can have more control over its messaging identity while still using third-party connectivity infrastructure. Equally, it can centralise bank communication without operating its own SWIFT environment.
The better question is not, “Do we want to own connectivity?” It is: which parts do we genuinely need to own?
3. Your real problem is formats and data
An own BIC will not fix inconsistent supplier data. It will not make two banks interpret pain.001 in exactly the same way. It will not convert MT940 into CAMT.053, route payment statuses back into your ERP or eliminate manual exception handling.
For many treasury teams, the hard part is not moving a message from A to B. It is making sure the message contains the right information, follows consistent rules and reaches systems that can use it. If those problems remain unresolved, an own BIC may simply give treasury a cleaner address for an untidy house.
4. “Independence” is the business case
Independence sounds attractive. But independence from what? From bank portals? From proprietary bank connections? From a connectivity provider? From internal IT?
These are different objectives. Using managed connectivity may increase dependence on a provider while making it easier to change banks. Operating more infrastructure internally may reduce vendor dependence while increasing dependence on scarce internal expertise.
Before using independence to justify an own BIC, identify the dependency that is actually causing cost, risk or delay.
5. You want more control, but nobody knows who will exercise it
More control is useful only when someone can act on it. Who investigates a failed payment close to cut-off? Who determines whether the problem sits in the ERP, the file format, the connectivity layer or the bank? Who owns onboarding when a new bank is added? Who maintains the controls as the architecture changes?
Owning more of the stack can create more control. It also creates more responsibility. If treasury cannot clearly assign that responsibility, the operating model may not be ready.
6. The business case is based mainly on size
“We process a lot of payments” is not enough. Neither is “we have hundreds of accounts.”
A company with high volumes through three standardised global banks may have a simpler connectivity problem than a smaller group operating across 20 countries, several ERP instances and numerous local banks. Complexity is driven by variation as much as scale.
The relevant questions are about bank diversity, geographies, payment types, resilience requirements, internal expertise and how often the environment changes. There is no universal transaction threshold at which an own BIC suddenly becomes sensible.
7. It feels like the next step in treasury maturity
This may be the most dangerous reason of all. Treasury architecture is not a maturity ladder where portals lead to host-to-host, host-to-host leads to SWIFT and SWIFT eventually leads to owning everything yourself.
A mature treasury owns the things that create strategic value and outsources the things that do not. For one organisation, greater ownership of its SWIFT setup may provide valuable independence and control. For another, the greater prize may be standardised processes, cleaner data, better ERP integration and fewer exceptions.
There is no prize for owning more plumbing.
Ask what you actually need to own
The decision is not simply own BIC versus managed connectivity. Identity, network access, connectivity, message transformation, ERP integration, bank onboarding and operational support are separate layers. Treasury can make a different ownership decision for each.
That leads to a better question: Which parts of our bank-connectivity architecture create enough strategic value that we should own them ourselves?
If an own BIC provides a clear answer to that question, it may be the right move. If it does not, there are probably more important problems 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.
