The business case for an own connected BIC is often built around independence, control and flexibility. Those benefits can be real. But the more important question starts after go-live: what changes operationally once the identity is yours?
An own connected BIC does not necessarily mean operating every part of SWIFT connectivity yourself. Infrastructure can still be provided by a service bureau or connectivity partner. What changes is the division of responsibility between treasury, IT, security, banks and external providers. That division is where much of the real operating challenge sits.
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.
The biggest risk is not necessarily that too much is outsourced or brought in-house. It is that nobody is quite sure where one party’s responsibility ends and another’s begins. A payment problem may originate in the ERP, message transformation, connectivity layer, security setup or receiving bank. The corporate does not need to operate every component, but it does need to know who owns what when something goes wrong.
Security illustrates the point. A provider can operate technical controls, but treasury still needs to know whether access reflects real business authority. A user may remain technically valid even though their role has changed. A legal entity may have been restructured. Responsibilities may have moved. The issue is therefore not simply whether security is outsourced, but whether technical access and business authority remain aligned over time.
The same applies to counterparty management. RMA and related controls may look technical, but the underlying question is commercial: which banks and services should the company actually be authorised to communicate with? Treasury may not administer the control itself, but it needs to remain connected to the business decision behind it.
SWIFT creates a common messaging environment, but it does not make banks identical. Banks can still differ in payment formats, implementation guidance, testing procedures, reporting options, cut-off times and acknowledgement behaviour.
An own connected BIC can create a more consistent foundation, but it does not remove the bank-specific work. The value is not that every new bank suddenly becomes easy to connect. It is that the corporate may avoid redesigning the entire connectivity architecture every time the banking landscape changes.
The same applies to change. 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. Uptime therefore tells only part of the story. The real challenge is keeping connectivity aligned with changing business processes, data and banking relationships.
This becomes most obvious during incidents. A connectivity provider may see a minor technical issue because most services remain available. Treasury may see a critical problem because the affected transaction is payroll, tax or a funding payment approaching cut-off.
That is why resilience needs to reflect business impact, not only technical severity. The same applies to continuity. A fallback channel is useful only if people can actually use it, access rights are current, approvals are understood and duplicate-payment risk can be controlled.
A fallback route that has never been tested is not resilience. It is documentation.
A service bureau or connectivity provider can remove substantial technical effort from treasury and IT. That may be exactly the right operating model. But outsourcing does not make governance disappear. It changes the type of work the corporate needs to do.
Instead of operating infrastructure, the company needs to understand service quality, escalation, security responsibilities, change management, concentration risk and what happens if the provider relationship changes. The strongest models are not those in which the corporate does everything itself, but those where each party does the work it is best equipped to perform and the boundaries between them are clear.
That is why the operating model belongs in the business case from the beginning. An own connected BIC may create useful separation between the corporate and the provider operating its connectivity, supporting portability and a more deliberate long-term architecture. But its value depends on whether treasury can govern the responsibilities that remain around it.
The business case should therefore look beyond implementation fees and connection scope. It should consider how responsibilities are divided, how change is managed, how incidents are escalated and how connectivity remains aligned with the company’s banking strategy.
An own connected BIC is not simply a connectivity decision. It is a decision about where treasury wants responsibility to sit for the long term.
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.