Blog

Why dozens of perfectly good bank portals can create one bad servicing process

Written by Matthias Varenkamp | Sep 16, 2026, 10:52:46 AM

There is nothing inherently wrong with a bank portal. Most do exactly what they are designed to do: give a client access to accounts and services held with that particular bank. The problem starts when a servicing business has to operate across dozens of them.

At that point, the question is no longer whether each individual portal works. It is whether the collection of portals creates a sensible operating environment for a business managing thousands of accounts, payments and client structures.

For credit servicers and loan administration businesses, that distinction matters. Banking is not a standalone activity. Information from banks has to feed wider servicing, reporting, payment and operational processes. If every banking relationship introduces another way of working, complexity starts to accumulate quickly.

About the author

Jeremy Slade is Head of Digital Solutions, Private Markets. He has more than 25 years of experience in financial services and has built and led businesses and commercial teams across Europe, Asia, the Middle East and the US. Having worked extensively with private markets and institutional investors, Jeremy brings a global perspective on how technology, banking and financial infrastructure are evolving.

 

Each bank can work well while the overall process becomes fragmented

Banks naturally design their platforms around their own relationship with the customer. A servicing business has a different challenge: it may need to operate across many banking relationships at the same time while maintaining consistent internal processes.

That creates a structural mismatch. One bank may provide information in one format, another may use a different reporting structure, and payment workflows, access arrangements and user administration can vary again.

Individually, none of those differences is necessarily a problem. Collectively, they can become one.

The result is that employees performing essentially the same task may have to work differently depending on which bank sits behind a particular account. Over time, those variations become embedded in the servicing process itself.

Fragmentation becomes much more visible at scale

For a company with a handful of bank accounts, switching between portals may be little more than an inconvenience. For a global servicing business, it can become a material operational issue.

Mount Street provides a useful example. Before implementing Cobase, its teams interacted directly with multiple banking platforms across different jurisdictions, working with different portals, reporting formats and processes. That banking environment sat within a much larger servicing operation involving several thousand bank accounts across dozens of banking partners and approximately 35,000 payments a year.

The important point is that those banking activities were not happening in isolation. Treasury needed information. Finance needed it. Loan Administration needed it. Regional teams needed it. Banking data also had to support wider servicing and reporting processes.

If the first step in any of those activities is determining which bank holds the account, which portal to use and how that bank presents the information, operational complexity starts appearing before the actual servicing work has even begun.

Bank-by-bank efficiency is not the same as servicing efficiency

This is why the problem is often misunderstood. “Too many portals” sounds like a minor usability complaint. The deeper issue is standardisation.

A servicer wants repeatable processes. Teams should understand how information enters the organisation, how payments are handled, how banking information is shared and how activity fits into the wider servicing environment.

But the underlying banking relationships may remain diverse. Different clients, structures and jurisdictions can bring different banks with them.

That means the organisation can end up with a paradox: every individual bank works perfectly well, yet the servicing process becomes increasingly fragmented.

The practical consequence is that internal operations begin to reflect the differences between banks rather than the servicing firm's preferred way of working.

The real test comes when something changes

Fragmentation becomes particularly expensive when the business moves outside routine activity.

A new mandate arrives. A new bank account has to be incorporated. A regional team needs access to information. A payment requires investigation. A reporting deadline suddenly becomes urgent.

At smaller scale, experienced employees can often navigate these situations through institutional knowledge. They know which portal to access, which process applies and where to find the information.

But institutional knowledge is not the same thing as a scalable operating model.

As the banking estate grows, the organisation becomes increasingly dependent on individuals remembering how multiple banking environments work. That may continue to function for a long time, but it becomes harder to standardise, train around and scale.

Mount Street's objective was therefore broader than simply simplifying access to bank portals. The firm wanted greater consistency in banking activity across jurisdictions, improved access to information and an operating model capable of supporting further growth.

The point of centralisation is not to make the banks disappear

For servicing businesses, centralisation should not be confused with forcing every client or structure onto the same bank. That may be neither desirable nor possible.

The underlying banking relationships remain. What changes is how the organisation interacts with them.

Mount Street says that moving to a common banking environment has given Treasury, Finance, Loan Administration and teams in different jurisdictions more consistent access to banking information. It has also made payment processing more streamlined and allowed teams to work from the same information rather than relying on different banking environments and processes.

That is a more important distinction than simply reducing the number of logins.

The value lies in reducing the amount of internal variation created by external banking relationships.

For a global servicing business, another bank should ideally be another relationship to support, not another miniature operating model that has to be recreated and maintained indefinitely.

Where Cobase fits

Cobase can provide a centralised layer across multiple banking relationships, giving servicing teams a more consistent way to access banking information, manage payments and work across different banks without changing the underlying client banking arrangements.

For organisations operating across large numbers of accounts, banks and jurisdictions, that can help reduce operational fragmentation while supporting a more consistent servicing model.