Travelex’s outage was every white-label bank’s outage

The week

On New Year’s Eve 2019, the foreign exchange company Travelex was hit by ransomware. Ransomware is malicious software that scrambles an organization’s files and systems so they cannot be used, after which the criminals demand payment for the key to unscramble them. The attack was widely attributed to a criminal group known as Sodinokibi, also called REvil.

Travelex took its websites and many internal systems offline, describing the step as a precaution to contain the infection. In some locations, staff went back to pen, paper and manual processes to keep serving customers at the counter. The company contacted the Metropolitan Police on January 2.

Travelex was then part of Finablr, a payments and foreign exchange group that had listed on the London Stock Exchange in May 2019. Travelex ran currency counters at airports and on high streets, a wholesale banknote business and a service that supplied travel money to banks and retailers.

During the first full week of January 2020, the damage spread well beyond Travelex itself. Several large UK banks and supermarket banks offered travel money that Travelex supplied and operated behind the scenes, sold under the banks’ own names. This arrangement is called white-labeling: one company makes the product and another sells it under its own label. Those banks now had to tell their customers that online currency orders were unavailable. Press coverage that month named, among others, Barclays, HSBC, First Direct, Virgin Money, Tesco Bank and Sainsbury’s Bank.

For a customer, it looked something like this. A family back from the holidays, with a ski trip booked, logs on to their bank’s website to order euros for collection. The page that normally takes their order says the service is unavailable. They call the bank. The person on the phone is apologetic and knows little more than they do. The family never knew that their bank did not run its own travel money service at all.

The criminals soon went public. According to the BBC, they demanded about $6 million and claimed to have copied around five gigabytes of customer data, including dates of birth and payment card details. Travelex said it had found no evidence that structured personal customer data had been encrypted. It later said it had no evidence that any data had been taken.

That position mattered for regulators. The GDPR still applied in the UK in January 2020. Under it, an organization must report a personal data breach to the Information Commissioner’s Office within 72 hours unless the breach is unlikely to put people at risk. The ICO said that week that it had not received a breach report from Travelex.

Security researchers pointed to unpatched remote access servers as a likely way in. Remote access servers are the systems that let staff connect to a company’s network from outside the office, and “unpatched” means the software fixes that close known security holes had not been installed. The flaw most often cited affected Pulse Secure VPN servers and was catalogued as CVE-2019-11510. Pulse Secure had released a fix in April 2019. One researcher said Travelex still had unpatched servers of that kind, and a threat intelligence firm said it had warned the company in September 2019. Travelex did not confirm those details that week.

Travelex was not an isolated case. The fix for the Pulse Secure flaw had been public since April 2019. The US National Security Agency and the UK’s National Cyber Security Centre had both warned about attacks on such VPN flaws in October 2019. According to the threat intelligence firm Bad Packets, at least 3,825 such servers were still unpatched on January 3, 2020. The REvil group also worked on an affiliate model, renting its ransomware to other criminals who carried out the intrusions. Any organization with an exposed, unpatched VPN was a candidate, and many of them supplied services to someone else.

Services came back gradually over the following weeks, starting with UK customer-facing systems in the second half of January. Some partner banks were still unable to take online currency orders three weeks after the attack, according to trade press reports. The banks whose names were on the product were left with two questions: when Travelex would recover, and why their own customers had been left in the dark.

The Travelex incident is usually remembered as a ransomware story: criminals, a ransom demand, systems going dark. For the banks that resold its service, it was really a procurement story, about how they had bought something and what they had failed to buy along with it.

They had outsourced a customer-facing product to one specialist, sold it under their own brand and managed the arrangement as a commercial partnership. When the partner failed, three costs landed on them at once: a visibility cost, a contractual cost and a concentration cost. Each needs a different control. Each control also has a price. It is easiest to pay at selection or renewal, when the bank still has bargaining power, rather than in the middle of a crisis, when it has none.

The rest of the article follows that order. It sets out the vocabulary and how such an arrangement runs on a normal day, then takes the three costs in turn. It closes with the habits that separate prepared banks from exposed ones, the same pattern in larger products, and the questions a risk committee should be able to answer.

Ransomware, patches and borrowed brands

Three ideas sit underneath this story, and each can be grasped without a technical background.

Ransomware

Ransomware is a type of malicious software that criminals slip into an organization’s computers. Once inside, it locks up files and systems by encrypting them, which means scrambling the data so that it is unreadable without a secret key. The criminals then offer to sell the key back. Modern ransomware gangs often also copy data before scrambling it and threaten to publish it, which adds a second kind of pressure.

Ransomware is a business disruption more than an IT event. When it works, the organization cannot take orders, pay suppliers or look up customer records. The IT team’s job becomes rebuilding systems from clean backups, which takes days or weeks, while the business works out how to keep serving people in the meantime.

How an attack like this unfolds

A ransomware attack on a company of this size is rarely a single event. It usually runs in stages over days or weeks. First the attackers gain a foothold, often through a remote access system or a stolen password. Next they raise their privileges until they control administrator accounts. Then they map the network, find the backups and copy out data they think will embarrass the victim.

Only at the end do they trigger the encryption, and they often choose a moment when staff are thin on the ground. A public holiday is ideal from their point of view. Fewer people are watching alerts, decisions take longer to reach, and the business may be at a seasonal peak. Travel money in early January is exactly such a peak, as families settle bills from Christmas and book trips for the months ahead.

The staging matters for the banks that depend on a provider. By the time the encryption is visible, the attackers may have been inside for weeks. The provider’s first statements will be based on incomplete forensic work. A bank that waits for certainty before acting will wait a long time.

How attackers get in

In the Travelex case, researchers pointed to unpatched remote access servers as the likely entry point. Remote access is convenient and necessary, but when a software maker announces a defect and ships a fix, someone has to install it. Those fixes are called patches. Criminals read the same defect announcements and go looking for systems where nobody has applied the fix yet.

The VPN flaw cited in the Travelex case shows why patching alone is not enough. That class of flaw let an attacker read files from the device without logging in, and those files could include the usernames and passwords of people who had recently connected. Installing the fix closes the hole. It does nothing about credentials already stolen. Suppose a company patches a remote access device months after such a flaw went public. It also needs to reset the passwords that passed through it, and to look for signs that someone has already used them.

White-labeling and third parties

White-labeling means one company builds and runs a product while another sells it under its own brand. Banks do this for many things: travel money, insurance, card services, even some savings products. A third party is simply any outside company that performs part of a service for you. When the third party is invisible to the customer, its failures become your failures in the customer’s eyes.

Arrangements of this kind come in several legal shapes, and the shape decides who answers to the customer. In some, the bank is the seller and the partner is its supplier. In others, the partner is the seller and the bank lends its name and website. The small print usually says which. That detail decides who handles complaints, who owes refunds and who must notify a data protection regulator when something goes wrong. Many business owners inside banks could not say which shape their own product has.

How a white-label arrangement works day to day

When a customer orders travel money through a bank’s website under an arrangement like this, the customer sees the bank’s logo, the bank’s colors and the bank’s web address. Behind the page, the order is passed to the partner’s systems, usually through an API, short for application programming interface. An API is a structured way for one company’s computers to send requests to another’s, much like a standard order form that both sides have agreed to use. The partner prices the currency, takes the order, arranges the cash and handles delivery or collection. The bank earns a share of the revenue.

Inside the bank, the arrangement usually touches several teams, each of which sees only part of it. A product or partnerships team negotiated the deal and watches sales volumes. Procurement or vendor management holds the contract and sends an annual questionnaire. The technology team maintains the connection between the two companies’ systems. The contact center answers customer calls, often using a script written when the product launched. Risk and compliance may have reviewed the partner once, at onboarding.

On a normal day, this works smoothly, and that is the trap. Because nothing goes wrong, nobody needs to know who would be in charge if something did. The partner’s security is assumed rather than examined, because it is someone else’s system. The customer’s data and money pass through a company the customer has never chosen, under terms the customer has never read. When the partner’s systems went dark in January 2020, each of those teams discovered at the same time that the piece they owned did not add up to a plan.

Where the money and the data go

Two flows run through the arrangement, and they often have different owners. The money flow starts when the customer pays by card on the ordering page. Depending on the contract, the payment may be taken in the partner’s name or the bank’s, and the currency is then delivered by courier or held for collection at a branch or a counter. The data flow carries the customer’s name, address, card details and sometimes identity documents for collection.

Data protection law asks who decides how that data is used. An organization that decides is a controller; one that acts only on another’s instructions is a processor. If the partner is a controller in its own right, it carries its own duty to notify the regulator of a breach. If it is a processor, the duty falls on the bank, which then depends on the partner to tell it what happened. Banks that had never settled this question found it hard to tell customers in January 2020 whether their data was at risk, or whose job it was to say.

Why a small product gets a small review

Most banks sort their suppliers into tiers, and the tier decides how much scrutiny each one gets. A common approach ranks suppliers by annual spend, because spend is easy to measure and correlates roughly with importance. A travel money partnership can earn the bank money rather than cost it, so on a spend basis it may barely register.

The result is a light-touch review: an annual questionnaire, a copy of a certification, perhaps a financial check. Nobody asks how the partner patches its internet-facing systems, how it keeps backups out of reach of ransomware, or how long it would take to rebuild. Those questions are reserved for the core banking platform and the card processor. The tiering model works as designed. It simply measures the wrong thing for products that carry the bank’s name.

The visibility cost

White-labeling works because the customer sees one brand, and for the same reason it fails badly. Customers who had ordered currency from their bank did not know Travelex was involved, so the outage read as the bank’s outage. Branch and contact center staff had to explain a dependency the customer had never been told about, often with no more information than the public had.

Three gaps made this worse. Front-line scripts did not exist, so each branch improvised. Status information came from the partner’s press statements, not from a direct operational channel. And nobody had agreed in advance what customers would be offered instead, such as a refund, a waiver of fees or a referral to another provider.

Suppose a mid-sized bank is caught this way. On the first morning, a customer calls about a currency order for a flight on Friday. The agent searches the internal knowledge base and finds nothing. A supervisor emails the product team, who email the partnership manager, who is reading the same news articles as everyone else. By the afternoon, dozens of agents have given dozens of slightly different answers, some promising refunds the bank has not authorized. No individual is to blame; this is the predictable result of nobody having planned for the partner failing.

The control is a short playbook for each white-label product. It names who inside the bank owns customer communication and sets the message for the first 24 hours. It lists the remedies front-line staff can offer without escalation, and the partner contact who will give the bank status updates. It costs a few days of work per product. A useful test is whether the contact center could brief its agents within an hour of a partner outage. If the honest answer is no, the bank is carrying reputational exposure that appears on no risk register.

Complaint handling is part of the same picture. Customers who could not collect currency before a trip, or who were unsure whether their order had gone through, complained to the bank whose name was on the product. Complaint teams need a way to tag such cases to the partner incident, so the bank can see the scale of harm, apply remedies consistently and recover costs where the contract allows. Without that tag, a partner outage disappears into general complaint statistics and never reaches the vendor review.

The first three days of a partner outage

A prepared bank runs a partner outage on a clock. In the first two hours, someone confirms the outage, ideally from the bank’s own monitoring of the connection to the partner rather than from customer complaints. The ordering page is switched to a written message that says what is happening and what customers can do, instead of a generic error. The contact center gets a holding script.

By the end of the first day, the product owner has agreed with the partner when the next status update will come. Remedies have been set, such as refunds for orders that cannot be fulfilled and fee waivers for customers who must buy currency elsewhere. Complaint tagging has started. Senior management has a short written summary.

By the third day, the questions shift to data. The bank needs to establish whether customer information was exposed, and who acts as controller for it. It needs to decide whether to notify its own regulator or data protection authority, and on what timetable. Legal should review the partner’s public statements for anything that commits the bank. Each step is simple. Without an owner and a clock, each one slips by a day, and the slippage compounds.

How it differs by type of firm

The shape of the visibility cost depends on how the firm meets its customers. A high street bank has branches and staff who face customers in person, which adds pressure but also gives it a channel to explain. A supermarket bank or a digital-only bank meets customers almost entirely online and through call centers, so a disabled web page and an uninformed agent are the whole experience. A US credit union offering a third-party prepaid travel card faces a smaller version of the same problem, with a membership that expects the credit union to know what its partners are doing.

Wealth managers and private banks face a sharper version. Their clients expect a named relationship manager to have answers, and a manager who learns about a partner outage from the client has lost ground that is slow to recover.

Whether to name the partner

One design choice shapes the visibility cost before anything goes wrong: whether the bank tells customers, up front, who runs the product. Naming the partner on the ordering page and in confirmation emails dilutes the brand a little. It also means customers are less surprised when the partner’s name appears in the news, and agents can explain the problem without seeming evasive.

Keeping the partner invisible protects the brand on good days and costs more on bad ones. Neither choice is wrong. The choice should be made deliberately, by the product owner with compliance, because it decides what the bank can credibly say when the partner fails. Later UK rules on consumer outcomes, described in the hindsight section, made that judgment harder to leave to marketing alone.

The contractual cost

Commercial agreements for niche services are often negotiated by business lines and focused on revenue share, branding and volume. That is natural: the people negotiating are measured on growth, and a travel money partnership looks like a small, profitable sideline. Incident notification timelines, forensic cooperation, audit rights, minimum security controls and the right to suspend or exit are easy to under-specify when the service is seen as peripheral.

In a ransomware event those clauses are the only tools the bank has. Without them, it waits for news like everyone else. A contract is a script for a bad day, negotiated in advance. If it is silent, the bank must ask for cooperation as a favor at exactly the moment the partner is most overwhelmed.

Specific terms matter more than general ones. A clause promising to notify the bank “promptly” of “material” incidents gives the partner room to decide what counts and when. A useful agreement instead does four things.

• It sets a notification window measured in hours.
• It requires the partner to share investigation findings that affect the bank’s customers.
• It gives the bank the right to see evidence of controls, such as patching of internet-facing systems and offline backups (copies of data kept disconnected from the network, so ransomware cannot reach them).
• It defines who pays for customer remediation when the partner causes the harm.

The practical fix is to tier white-label and embedded partners by customer impact rather than contract value. A low-spend arrangement that touches customers directly should carry the same incident, security and exit terms as a core processor. Vendor management teams should be able to list which customer-facing contracts lack those terms, with a date to close each gap.

Partners will price stronger terms into their fees. That price is the cost of the product, and the business case should carry it. A board that approves a white-label product on the basis of revenue without seeing the cost of the protections is approving an incomplete picture.

The clauses that decide a bad week

Beyond those four, several terms tend to matter most once an incident is under way. One is the partner’s duty to pass the same obligations down to its own suppliers, sometimes called fourth parties. A travel money provider depends on couriers, payment processors and hosting firms, and a gap at any of them is a gap for the bank.

Another is access to investigation findings. After a serious attack, the provider’s lawyers will usually commission the forensic investigation and try to keep the full report confidential. A bank that has not negotiated the point may receive nothing more than a press statement. A workable compromise is a written summary of root cause, scope and remediation, delivered by a set date, or a letter from the investigating firm.

A third is the limit of liability. Commercial contracts commonly cap each side’s liability at some multiple of the annual fees. For a niche product, that cap may be trivial next to the cost of refunds, complaint handling and goodwill payments. Banks often negotiate a separate, higher cap for data breaches and security failures. Evidence of cyber insurance, and the right to see it, belongs in the same conversation.

The last is exit. A right to terminate after a security breach is easy to write and hard to use, because the bank needs somewhere to send its customers. Exit clauses only have value when they come with obligations to return and delete data, and to support a transition for a set period.

When the bank is the smaller party

The strongest objection to all of this is bargaining power. A large provider serving many banks may simply refuse bespoke terms, and a small bank or credit union has little to offer in return. That is a fair point, and it changes the method rather than the goal. Smaller institutions can use standard security addenda shared through industry groups, rely on pooled assessments, or accept weaker terms while recording the gap and setting a fallback. What they should not do is sign without knowing what the contract leaves out.

The concentration cost

The third cost was systemic. Several brands relied on the same provider, so a single compromise removed the service across a meaningful part of the market at once. No single bank’s due diligence would have revealed that. Each assessed Travelex in isolation, and each might reasonably have concluded that the provider was competent and well established.

Concentration risk is what happens when many organizations depend on the same supplier. It works like a town where every restaurant buys its bread from one bakery. Each restaurant’s choice is sensible. But if the bakery’s oven breaks, there is no bread anywhere in town, and customers cannot simply walk across the street to a competitor.

Concentration risk is a market-level property, and a bank can only manage its share of it. That starts with knowing which critical and customer-facing services depend on providers that many peers also use. Industry bodies, examiners and the provider itself can often confirm how widely a service is shared. The bank then has three options for each such service: pay for a second provider, maintain a manual fallback, or accept the risk explicitly at an appropriate level of management.

Shared providers also tend to be specialists whose security budget is sized for a niche business, not for the combined exposure of every brand that depends on them. Their clients can sometimes assess them jointly, or rely on a common independent assessment, which is cheaper and more searching than each bank running its own questionnaire.

Each of these choices has a cost, and acceptance is sometimes the right answer. A second provider for a modest product line may cost more than the revenue it protects. What matters is that the decision is made deliberately, by someone with the authority to make it, and written down. What a board should see is a list of products sold under the bank’s brand but operated by someone else, with an owner, a fallback decision and the date that decision was last reviewed. For most institutions, assembling that list is a modest exercise that turns up at least one surprise.

Seeing concentration from inside one bank

A single bank has limited means of measuring concentration. It can ask the provider how many other financial institutions it serves, though the answer may be vague. It can compare notes with peers through industry bodies, within the limits of competition law. It can watch for clues, such as the same provider’s name in the small print of competitors’ products.

Supervisors have a better view, because they see many firms at once. Much of the later regulatory work on third parties, described in the hindsight section, was built for this purpose. It gave supervisors new tools: registers that list which firms rely on which providers, and powers over providers that many firms share.

The case for accepting the risk

The strongest counter-argument to this article is that the banks behaved rationally. A specialist provider is often better at its niche than a bank would be. Building a second integration costs money and adds its own failure points. Travel money is a small, seasonal product, and an outage of a few weeks caused annoyance more than lasting harm.

Much of that holds. Diversifying every small product would cost more than it saves. The argument breaks down in two places, though. First, the cost of an outage does not stay inside the product line: it lands on the contact center, the complaint team and the brand. Second, acceptance is only a decision if someone makes it. In many banks, nobody had made it at all. The risk had simply never been looked at.

What the obvious response breaks

The reflex after an incident like this is to switch providers or pull the product. Both have side effects. Moving customers to a new provider mid-crisis puts a sudden load on a firm that did not plan for it. It also strains an integration that has not been tested at volume. Pulling the product may push customers to competitors who still offer it, sometimes through the same provider once it recovers. A calmer response is to keep the provider, demand evidence of remediation, and fix the playbook, contract and fallback before the next renewal.

Fallbacks that work on the day

A manual fallback is only useful if it has been tried. For a product like travel money, a workable fallback has three parts. One is a standing referral arrangement with a second provider. The others are a prepared web page that sends customers there and an agreed way to handle orders already placed. Each piece takes some effort to set up and almost none to maintain.

The test is simple. Once a year, during a slow season, the product team walks through the switch on paper with the contact center, the web team and the second provider. If any step depends on a person who has since left, or a contract that has lapsed, the fallback is a fiction. Recording the result of that walk-through is also the evidence a supervisor will ask for.

Habits of a bank that is ready for a partner to fail

Banks that handle white-label risk well tend to share a handful of habits.

• It knows its list. There is a single, current register of products that carry the bank’s brand but are run by someone else, and it is reviewed at least annually.
• Every product has a business owner. Not a procurement contact, but a named executive accountable for the customer experience when the partner fails.
• The playbook has been rehearsed. A tabletop exercise, in which the team talks through a simulated outage around a table, has been run at least once, including the contact center.
• Contracts match customer impact. Customer-facing partners carry hour-level notification, control evidence and exit rights, regardless of how small the contract is.
• Shared dependencies are visible. Where a provider serves many peers, the bank has made and recorded an explicit fallback decision.

The failures are just as recognizable. One is treating a partner as a revenue line rather than as part of the bank’s operations, so that oversight sits with the team that benefits from the deal. Another is relying on the partner’s certifications and questionnaires alone, without asking for evidence of the specific controls that matter, such as patching of internet-facing systems. A third is a playbook that lives in a shared drive and that nobody in the contact center has seen. And it is easy to assume that because a provider is well known, someone else must already have checked it. In a concentrated market, everyone may be assuming the same thing.

Two simple measures make these habits visible to a board. One is the time it takes the contact center to brief agents after a partner outage, measured in an exercise rather than estimated. The other is the share of customer-facing contracts that carry hour-level notification, evidence rights and exit terms. Both can be tracked quarterly, and both move only when someone does the work.

The same pattern in much bigger products

Travel money is a small product for most banks, which is precisely why it makes a good teaching case. The same pattern applies to far larger arrangements: card processing, mortgage servicing, online banking platforms, cloud hosting and customer identity checks. In each, a customer sees the bank’s name, while the work is done by a firm the customer has never heard of.

The consequences touch every part of the business. Revenue is lost while the service is down. Costs rise as complaint handling, refunds and goodwill payments mount. Staff are put in a difficult position, apologizing for something they cannot explain. Regulators increasingly treat a third party’s failure as the regulated firm’s failure. And reputation suffers in a way that is hard to recover, because customers do not distinguish between a bank and its suppliers.

The controls described here need no new technology. What they need is a set of decisions made before the bad day arrives. The bank must decide who owns the customer relationship when a partner fails, what the contract allows the bank to demand, and what happens if the provider many peers rely on goes down.

The inverse arrangement

There is also a mirror image of white-labeling that grew quickly after 2020. In banking-as-a-service models, a fintech puts its own brand on an account or card, and a licensed bank holds the deposits in the background. The customer sees the fintech’s name; the bank’s appears in the small print. The bank still answers to its regulator for the accounts, even though it does not own the customer relationship. Every point in this article about visibility, contracts and concentration applies, with the roles reversed.

Who answers to which supervisor

The rules that govern these arrangements differ by type of institution, and organizations should check the specifics with counsel. In the UK, banks answer to the Prudential Regulation Authority and the Financial Conduct Authority for outsourced and third-party services. In the US, national banks, state banks and bank holding companies are supervised by the OCC, the FDIC or the Federal Reserve. Under the Bank Service Company Act, those agencies can examine many of the firms that provide services to banks.

Federally insured credit unions are in a different position. Their regulator, the National Credit Union Administration, lost its temporary authority to examine credit union vendors directly at the end of 2001. It has asked Congress to restore it, so far without success, which leaves credit unions with more of the burden of overseeing their partners themselves. Broker-dealers answer to the SEC and FINRA, whose supervision rules make the firm responsible for activities it outsources. Firms operating in the EU fall under the rules described in the hindsight section.

What the risk committee should be able to see about white-label partners

A senior executive or board member can ask these without any technical preparation. The answers, and how long it takes to get them, will say a great deal.

1. Which products do we sell under our own name that another company actually runs, and can you show me the list today?
2. If our biggest white-label partner went offline tomorrow morning, how long would it take to brief our contact center agents, and what could they offer customers without asking permission?
3. Which of our customer-facing contracts lack an incident notification window measured in hours, and when will each gap be closed?
4. Where is it written down who pays for refunds and goodwill gestures when a partner’s failure harms our customers?
5. Which of our providers are also used by many of our peers? For each, have we chosen a second provider, a manual fallback or explicit acceptance, and who signed off?

With hindsight

Travelex restored services over the following weeks, but the business did not recover its footing. The pandemic collapsed international travel within months, which for a company built on selling currency to travelers was close to the worst possible blow. Its parent, Finablr, ran into its own crisis in the spring of 2020, suspending trading in its shares after disclosing previously unknown financing arrangements.

In August 2020 parts of the group entered administration in the UK, a formal insolvency process. A pre-arranged sale moved the business to a new group owned by its creditors, with much lower debt. More than 1,300 UK jobs were lost, and Travelex closed its high street counters in the UK.

In April 2020 the Wall Street Journal reported that Travelex had paid the attackers about $2.3 million in bitcoin. Whether the attack or the pandemic did more damage is hard to separate, but the combination showed how a provider weakened by one shock can fail under the next. For the banks that depended on Travelex, that was sobering: a partner’s resilience depends on how much reserve it has left when a second shock arrives, as well as on whether it survives the first.

Regulators have since moved firmly to the view that third-party failures are the regulated firm’s problem. In the UK, where the affected banks sat, the operational resilience rules took effect in March 2022 and required firms to stay within impact tolerances for important business services by March 2025, whoever operates them. An impact tolerance is the maximum disruption a firm says it can allow, for example how long a service can be down, before customers suffer intolerable harm. The phrase “whoever operates them” carries the weight: outsourcing a service does not outsource the responsibility. The Prudential Regulation Authority’s supervisory statement on outsourcing and third-party risk, published in March 2021, set out what it expected from contracts, data, access rights and exit plans.

The UK then went further. The Financial Services and Markets Act 2023 gave HM Treasury the power to designate critical third parties to the financial sector, and the regulators’ rules for those providers took effect on January 1, 2025. The regime lets the regulators oversee the services such a provider supplies to many firms at once, which addresses the concentration problem no single bank could see. It sits alongside the firms’ own duties rather than replacing them.

In the US, the banking agencies adopted a computer-security incident notification rule in November 2021, with compliance required from May 2022. Banks must notify their primary federal regulator within 36 hours of determining that a serious incident has occurred. Bank service providers must tell affected bank customers as soon as possible when an incident has disrupted, or is likely to disrupt, covered services for four hours or more. That obligation is close to the hour-level notice clause that the Travelex episode showed banks lacked.

The US banking agencies also issued final interagency guidance on third-party risk management in June 2023. FINRA reminded broker-dealers in 2021 that outsourcing an activity does not relieve them of supervisory responsibility for it. The EU’s Digital Operational Resilience Act has applied since January 2025, with explicit expectations on ICT concentration and exit planning. Firms must think about how many of them rely on the same technology providers and how they would leave one if they had to. In November 2025 the three European supervisory authorities published their first list of ICT providers designated as critical under the act.

Later events kept the pattern visible. In 2024 the collapse of Synapse, a middleware firm that linked fintech apps to partner banks, left many end customers unable to reach their money for months while records were reconciled. Customers had dealt with fintech brands and had little idea which bank held their funds. It was the inverse arrangement described above, failing in the same way.

The questions Travelex raised informally are now asked formally in examinations. The list of branded products run by others, the playbook for a partner outage, the contract terms and the fallback decisions are no longer good housekeeping. They are what supervisors expect to see, and what customers assume is already in place. What has not changed is the timing: the protections are still cheapest to buy at signing or renewal, and dearest in the week a partner goes dark.