This article is written by Cobase
For an industry built on numbers, banking has always struggled with something more basic: speaking the same language.
Ask any treasury team trying to connect to banks globally and you’ll hear a familiar frustration. The expectation is simple – money is digital, banks are global, so connectivity should be straightforward. In reality, it rarely is. What looks like a plumbing issue is something deeper: a system that was never designed to be unified in the first place.
Modern banking didn’t emerge as a coordinated network. It grew in fragments. National systems were built to serve domestic economies, shaped by local regulation, infrastructure, and political priorities. Payment schemes evolved independently. Messaging formats were defined in isolation. Even basic concepts like how to confirm a payment or report a balance took different forms depending on where you looked.
The result is not just variation, but incompatibility.
SWIFT is often held up as the closest thing to a global standard. And in one sense, it is. It created a common messaging layer that banks across the world could use. But it never standardised what happens after the message is sent. Two banks can receive the same SWIFT instruction and process it in entirely different ways – different cut-off times, different validations, different interpretations.
This is where the idea of “bank connectivity” begins to unravel. The challenge is not just reaching a bank, but dealing with how each bank behaves once you do.
Over the years, the industry has made repeated attempts to smooth this out. None have fully succeeded. Not because the technology wasn’t good enough, but because the incentives never aligned. Banks compete. Regulators don’t coordinate globally. And legacy systems – often decades old – continue to run critical infrastructure that no one is willing to replace lightly.
The expectation of a unified system persists. But it’s built on a false premise.
Banking isn’t fragmented because something went wrong. It’s fragmented because that’s how it was built.
Few ideas in banking have generated as much optimism in recent years as APIs.
They arrived with the promise of simplicity. Clean, modern interfaces. Real-time data. Standardised access. Compared to the heavy, file-based integrations of the past, APIs looked like a reset moment, a chance to finally make bank connectivity behave like the rest of the digital world.
And in some ways, they delivered.
Large banks began exposing endpoints for payments and reporting. Developers could interact with bank systems without navigating layers of legacy protocols. In controlled environments, things worked exactly as advertised.
But step outside those environments, and the picture changes.
APIs in banking are not a single standard. They are dozens, sometimes hundreds, of individual implementations. Each bank defines its own structure, its own authentication methods, its own limits. Even when two banks claim to follow the same framework, the differences show up quickly – in edge cases, in error handling, in performance under load.
The regulatory push behind open banking added momentum, but also confusion. PSD2 created a baseline, but it was never designed for corporate treasury. It focused on retail use cases, with limited scope for bulk payments, complex approval flows, or multi-entity structures. For large organisations, it solved a small part of a much bigger problem.
Meanwhile, neo-banks and aggregators entered the picture, offering simplified access and faster onboarding. They improved the experience at the edges, particularly for account opening and basic transactions. But they didn’t remove the need to engage with traditional banks. In many cases, they simply added another layer to manage.
The result is a familiar pattern in financial infrastructure. New technology doesn’t replace the old – it accumulates around it.
APIs didn’t eliminate fragmentation. They made it more dynamic.
From the outside, bank connectivity looks deceptively simple. Payments go out, balances come in, and everything appears to move through a single system.
What’s less visible is the machinery underneath.
For companies operating across multiple countries, connectivity is not one connection, it’s dozens. Each bank brings its own requirements. File formats differ. Security models vary. Some require certificates, others tokens. One bank processes payments in batches, another in real time. Cut-off times shift by region, sometimes by product.
Even within the same bank, behaviour can change depending on the channel used. An API might support one set of payment types, while host-to-host supports another. Documentation doesn’t always reflect reality. Test environments behave differently from production. Exceptions are handled inconsistently.
None of this is unusual. It’s the normal state of the system.
This is why, despite all the talk of innovation, older methods remain firmly in place. Host-to-host connectivity – direct, file-based integration – continues to handle a large share of corporate payments. It’s not elegant, but it’s predictable. It does what it’s supposed to do, at scale, without surprises.
In certain markets, local standards dominate. EBICS, for example, is deeply embedded in parts of Europe. It works not because it’s globally relevant, but because it reflects the specific needs of those markets. In those contexts, it often outperforms more “modern” approaches simply by being consistent.
And then there’s SWIFT, still acting as the global fallback. When no direct connection is available, SWIFT is usually there. Not perfect, not always efficient, but broadly accepted.
Put all of this together, and a pattern emerges. There is no single best way to connect to banks. There is only a set of trade-offs.
The real work is not choosing one method, but managing all of them at once, and making them behave as if they were one.
That work increasingly sits in a layer most corporates never set out to build, but inevitably do: an orchestration layer that absorbs differences between banks, channels, and formats, and presents something coherent on top.
This is where platforms like Cobase operate.
Rather than trying to standardise banks themselves, Cobase standardises the interaction with them. It connects across SWIFT, EBICS, APIs, and host-to-host channels, translating between formats, normalising data, and embedding bank-specific behaviour into a central system. A payment instruction created once can be converted automatically into whatever each bank requires. Data coming back – balances, statuses, confirmations – is aligned into a consistent structure.
The complexity doesn’t disappear. It is relocated.
Instead of sitting in day-to-day treasury operations spread across teams, spreadsheets, and manual fixes, it is contained within a controlled layer designed to handle it.
Because in the end, the hardest part of bank connectivity is not building connections.
It’s making them invisible.
Treasury Masterminds is a community of professionals working in treasury management or those interested in learning more about various topics related to treasury management, including cash management, foreign exchange management, and payments. To register and connect with Treasury professionals, click the button below.
By Alexander von Schirmeister,
CEO at Nomentia
A bank portal still works. The ERP still produces data. A spreadsheet still calculates a forecast. A payment approval workflow still moves from one person to the next. Reports still reach the CFO, even if they arrive later than expected. From the outside, treasury appears to function. Inside the process, finance teams know exactly how much effort is required to keep that appearance of control intact.
Modern treasury cannot rely on disconnected systems because the questions it needs to answer are no longer isolated. Cash visibility depends on bank data, account structures, ERP information, payments in progress, forecast inputs, intercompany flows, financing activities, and exposures. Liquidity planning depends on operational data from the business, but also on treasury assumptions, market conditions, working capital movements, and funding plans. Risk management depends on reliable exposure data, but also on trade execution, hedge documentation, limits, reporting, and accounting. If each part of this picture sits in a different place, the treasury team becomes the integration layer.
That integration work rarely surfaces. It lives in copy-and-paste routines, manual file checks, email reminders, reconciliation notes, spreadsheet tabs, and individual memory. It is also where most treasury management challenges quietly begin.
Disconnected systems create time loss because data has to be gathered before it can be analysed. They create duplicated work because teams maintain local trackers even when central tools exist. They weaken cash visibility because the latest view may depend on which bank file has arrived or which entity has responded. They weaken controls because exceptions are harder to identify when workflows are not connected.
The CFO does not usually see the process friction. The CFO sees the answer. If the answer is late, inconsistent, or hard to explain, confidence falls. Senior leadership needs reliable responses to simple but high-stakes questions: How much liquidity is available? Which cash flows are expected? Where is working capital tied up? Are internal payments efficient? Which exposures are material? Are guarantees, hedges, and commitments under control? These questions cannot be answered well when the data behind them has to be rebuilt every time.
The 2026 Nomentia Treasury and Cash Management report highlights that many treasury teams are in a transitional phase. They have moved beyond purely manual treasury, but still rely on multiple systems and partial automation. The pattern is familiar: the organisation has invested in technology, yet treasury still spends too much time reconciling information and validating reports. The issue is not that systems are missing. The issue is that they are not connected enough to support the pace of decision-making.
Disconnected systems are especially risky in three areas.
The first is visibility. If cash positions, transactions, forecasts, and payment statuses are not consolidated, treasury may see parts of the picture but miss the direction of movement. A balance report can show where cash is today, but it does not explain whether the position is temporary, restricted, exposed, or needed elsewhere in the group. Visibility without context can create false comfort.
The second is control. Treasury policies often look clear on paper, but control depends on how processes actually run. Who can approve a payment? Which entities have followed the forecast process? Which exposures have been validated? Which guarantee is close to expiry? Which hedge relationship needs attention? When workflows are disconnected, control becomes dependent on manual follow-up. That may work when volumes are low, but it becomes unreliable as banks, entities, instruments, and reporting expectations increase.
The third is decision speed. In volatile markets, delayed answers are not neutral. A late forecast can affect funding decisions. A delayed exposure view can affect hedge timing. A slow payment status check can affect supplier confidence. A late view of guarantees or credit line usage can affect working capital decisions. Treasury does not need real-time data for every decision, but it does need enough connected information to avoid making decisions with yesterday’s understanding.
A modern treasury management system should not be judged only by feature breadth. The more important question is how well it reduces the gaps between systems, data, workflow, and reporting. A strong setup connects bank information, ERP data, payment processes, cash forecasting, risk workflows, analytics, and audit trails into a reliable operating model. That does not mean every company needs every module at once. It means the architecture should support growth without forcing the team to rebuild its processes every time complexity increases.
Most people researching a TMS today will start with a web search or ask Copilot, Gemini, or ChatGPT. The answer they get back is usually a feature list. That’s not wrong, but it’s incomplete. A good treasury management system helps finance teams centralise cash, payments, forecasting, risk, controls, and reporting so they can make better liquidity and financial risk decisions with trusted data. Features are how it gets there. That’s the distinction worth keeping in mind when evaluating whether your current setup is still fit for purpose.
The path away from disconnected systems does not always require a large replacement project. In many organisations, the better approach is to identify the most painful manual bridges first. Where does treasury re-enter data? Where does the team wait for local input? Where do reports need manual explanation? Where are approvals outside the system? Where is the same number calculated in different ways? These questions show where fragmentation is creating the most business risk.
Connected systems create reliable answers. They reduce the manual work behind cash visibility, improve the quality of cash flow forecasting, and support stronger controls and compliance. They help the CFO understand not only what the numbers are, but what they mean for liquidity, risk, and action. Disconnected systems may still function. But they make treasury work harder than it should, and confident decisions harder than they need to be.
Treasury Masterminds is a community of professionals working in treasury management or those interested in learning more about various topics related to treasury management, including cash management, foreign exchange management, and payments. To register and connect with Treasury professionals, click the button below.
This article is written by TreasuryCube
In an increasingly complex financial environment, In-House Banks (IHBs) have emerged as a strategic imperative for corporations seeking enhanced cash visibility, optimized liquidity, and streamlined intercompany transactions. Drawing insights from a recent presentation by experts at Citi and seasoned treasurers, let’s explore what makes an IHB not just an option, but a cornerstone of modern treasury management.
An IHB is a centralized internal financial entity that manages cash, investments, foreign exchange exposures, and intercompany lending on behalf of corporate subsidiaries. Acting as a “virtual bank” for the organization, it reduces the volume of external banking transactions and provides critical advantages in cash management, governance, and compliance.
Importantly, an IHB is not a regional treasury center, shared service center, re-invoicing hub, or physical licensed bank. It’s a bespoke solution that integrates deeply with corporate finance operations.
An IHB addresses several core challenges that treasurers face:
Real-world IHB implementations, like those led by Brook Ballard at Oceaneering, showcase the tangible benefits:
Intercompany netting further reduces payment transactions, bank fees, and FX costs by consolidating cross-border intercompany settlements.
While beneficial for many, IHBs are particularly advantageous for:
At TreasuryCube, we recognize that the modern treasury is not just about managing cash, it’s about unlocking strategic value. An effective IHB is a critical tool to help achieve that vision, especially when supported by integrated technology, skilled people, and proactive governance.
Treasury Masterminds is a community of professionals working in treasury management or those interested in learning more about various topics related to treasury management, including cash management, foreign exchange management, and payments. To register and connect with Treasury professionals, click the button below.
This article is written by our partner, FIS
The reality of payment fraud has shifted from a question of whether an attack will occur to a growing likelihood of when and how it will occur.
For finance and treasury leaders, the strategies that provided a sense of security a few years ago may be insufficient against a new breed of sophisticated and relentless criminals. A 2024 survey from the Association for Financial Professionals underscored this reality, revealing that a staggering 79% of organizations were victims of payment fraud attacks or attempts.
This is not a distant risk: It’s an active, daily threat that demands a fundamental change in an institution’s defensive posture. The traditional, reactive approach – detecting and responding to fraud after it occurs – is, in many cases, no longer a viable strategy. The time has come to build a proactive defense.
Today’s fraudsters are often not lone actors but organized, well-funded operations that use advanced technology and psychological tactics. They study organizational structures, identify process gaps and exploit the path of least resistance.
Business email compromise remains a dominant method, where criminals impersonate executives or vendors with alarming authenticity to redirect funds. We’re also seeing the rise of AI-powered deep fakes, where a trusted voice on a conference call can be convincingly spoofed to authorize a fraudulent transfer.
These criminals understand that the entire payment lifecycle, from the initial onboarding of a vendor to the final reconciliation, presents a landscape of opportunity. They target the seams in your processes, exploiting the very human desire for efficiency and speed. This “disharmony,” a term coined by a FIS® and Oxford Economics study, captures the friction between the drive for growth and the drag of persistent security threats.
According to the study, 75% of C-suite executives identify fraud as a critical challenge.
How can organizations overcome the evolving threat of fraud? The answer lies in shifting from a fragmented, manual and reactive stance to an integrated, automated and proactive one.
A truly effective defense begins by fortifying the most common entry points. The vendor master file, for instance, is the heart of the payables process and a prime target. A single fraudulent change to a supplier’s bank details can lead to catastrophic losses before anyone realizes an error has occurred.
Overcoming this type of threat typically requires more than just diligence: It often demands a standardized, technology-enforced process. It includes implementing out-of-band verification, such as a phone call to a preverified contact, for any change to payment instructions. It means moving beyond trust and implementing strict, automated validation protocols.
As transaction volumes grow, manual reviews can become an impossible bottleneck, creating the very noise that criminals use to hide their illicit activities. This is where modern solutions like AI-assisted anomaly detection become increasingly indispensable.
Unlike static, rule-based systems that can only catch what they are programmed to look for, AI and machine learning establish a baseline of “normal” payment behavior for each vendor and transaction type. These systems operate in real time, analyzing payments for subtle deviations in amount, frequency or timing that would be difficult for the human eye to detect. When an anomaly is detected, the payment is automatically flagged for investigation before it leaves the organization. This preemptive capability is a game changer.
Organizations can achieve a greater level of control by consolidating their payment flows through a centralized payment hub. Instead of managing disparate security protocols across multiple ERPs and bank portals, a payment hub provides a more unified point of visibility and control.
A payment hub enables the consistent application of security policies, approval workflows and fraud detection analytics across the entire enterprise. It standardizes an institution’s defense, creating a fortress rather than a series of disconnected fences. A payment hub integrated with a third-party account validation service provides another critical layer, confirming that a beneficiary’s name matches their account information before a payment is ever initiated.
Reduce fraud risk and strengthen controls with FIS Payment Hub – Enterprise Edition
The path forward for finance and treasury leaders requires a strategic pivot. It means recognizing that fraud prevention is not merely a compliance checkbox but a strategic enabler of business resilience and growth.
Building a proactive defense involves a holistic approach that integrates advanced technology, standardized processes and a culture of vigilant verification. By embracing AI-driven monitoring, centralizing payment operations and empowering employees with specialized training, you can transform your security posture from reactive to preemptive.
This shift does not just mitigate risk: It builds the confidence and operational integrity necessary to thrive in a complex financial world.
Treasury Masterminds is a community of professionals working in treasury management or those interested in learning more about various topics related to treasury management, including cash management, foreign exchange management, and payments. To register and connect with Treasury professionals, click the button below.
