A cluster of fresh payment and funding incidents across Nigeria, Spain, Zambia and crypto exchange Kraken is exposing a less visible form of infrastructure risk: systems that recover, fail again or break only at a specific upstream layer while the customer-facing platform itself remains online.
On October 8, dLocal recorded overlapping processing problems involving Interswitch and Guaranty Trust Bank in Nigeria. Tink detected a Banco Sabadell payment outage affecting 90% of monitored users less than a day after closing another Sabadell Open Banking problem. PawaPay reported yet another degradation of its Zamtel NFS payout gateway in Zambia.
Separately, Kraken finally closed a funding incident that had affected 23 blockchain networks for more than 33 days.
There is no evidence that these incidents are related. Their technical causes involve different companies, countries and infrastructure. What they have in common is more operational: each shows how financial platforms can remain available while a dependency underneath them becomes unreliable.
dLocal Saw Interswitch and GTBank Fail at the Same Minute
The most intriguing timing came from Nigeria.
dLocal identified processing problems involving Interswitch at 00:26 UTC on October 8 and said it had contacted the processor.
Its official incident history shows a Guaranty Trust Bank processing incident beginning at exactly the same time: 21:26 in dLocal’s GMT-3 status-page timezone on October 7, equivalent to 00:26 UTC on October 8.
The GTBank problem lasted until 02:06 UTC.
Only three minutes after dLocal marked it resolved, another GTBank processing incident began at 02:09 UTC. That second event continued until 02:59 UTC.
The identical initial timestamp naturally raises the possibility that GTBank traffic was exposed to the Interswitch disruption. But the public incident records do not establish that connection.
GTBank could have experienced an unrelated bank-side problem at the same time. dLocal has not publicly identified a common root cause or said that the GTBank transactions were routed through the affected Interswitch infrastructure.
There is, however, independent evidence that Interswitch was having difficulties.
Flutterwave warned merchants on October 7 that some NGN card payments were failing because of an issue affecting Interswitch. The provider said Interswitch was aware of the problem and working to restore service.
dLocal had also logged Interswitch incidents on October 4 and October 5, making the latest disruption part of a recent sequence rather than a completely isolated alert.
Sabadell Lost 90% of Tink’s Payment Flow Hours After an Earlier Incident Ended
Spain produced a different type of repeat failure.
Tink’s automated monitoring detected a new Banco Sabadell payment outage beginning at 01:34 CEST on October 8. Tink said 90% of users were affected in the payments flow and classified the problem as a bank-side payment error.
The outage was resolved at 07:08 CEST, giving it a duration of approximately five hours and 34 minutes.
What makes the incident more notable is what happened immediately before it.
Tink had closed a separate Banco Sabadell Open Banking degradation at 09:56 CEST on October 7, only about 15 hours and 38 minutes before the new payment failure began.
The earlier incident had been open since September 25.
At one point on September 30, Tink said 100% of users were affected across manual authentication, manual refresh, automatic refresh and payment initiation, with HTTP 500 errors hitting the Accounts, Consent and Payments endpoints. Tink identified the connection as es-redsys-sabadell-ob.
By the time it closed on October 7, the remaining problem involved automatic account refreshes and affected 33% of users.
The new October 8 outage may be separate. Tink has not said the same Redsys integration caused it, and the newer status record identifies only a bank-side payment error.
Still, repeated failures across both account-data and payment-initiation functions make the dependency structure worth examining.
Zamtel NFS Has Become a Recurring PawaPay Failure Point
PawaPay’s Zambia incident shows another pattern: the same mobile-money connection repeatedly degrading over a short period.
The latest Zamtel NFS event began at 21:12 UTC on October 7, or 00:12 Cairo time on October 8.
By 04:38 UTC, PawaPay said the Zamtel NFS payout gateway remained degraded and that it was following up with the mobile-money operator.
Zamtel subsequently deployed a fix, and PawaPay moved the incident into monitoring at 09:57 UTC after observing improving success rates.
This was not the first recent failure.
A Zamtel NFS outage beginning September 29 remained impaired overnight and was not resolved until September 30. Another NFS incident occurred on October 1. Zamtel services were also disrupted again on October 5 and October 7.
PawaPay’s own status page makes the infrastructure split explicit: its core platform, merchant API, dashboard and reconciliation service can remain operational while an individual mobile network operator’s gateway is degraded.
That architecture gives merchants access to multiple mobile-money operators through one integration, but it also means an upstream operator can become the effective availability bottleneck.
The same dependency problem is central to the wider move toward financial middleware. Dave Finances previously examined how fintech companies are trying to compress multiple banking and payment layers into unified infrastructure. The operational benefit is simplicity for the user; the risk is that failures can become difficult to attribute when several companies sit between the merchant and the final rail.
Kraken Took 33 Days to Close One 23-Network Funding Incident
The longest-running event in the group came from Kraken.
The exchange opened its “Funding delays for select blockchain networks” incident at 21:43 UTC on September 4 and finally marked it resolved at 22:25 UTC on October 7 — 33 days and 42 minutes later.
Kraken initially said deposits were temporarily paused and withdrawals could be unavailable or delayed across 23 networks, including Akash, Babylon, Celestia, Cosmos Hub, Coreum, dYdX, Dymension, Fetch.ai, Initia, Injective, Juno, Kava, MANTRA, Neutron, Nym, Osmosis, Saga, Secret Network, Sei EVM, Stride, Terra, Terra Classic and THORChain.
Kraken gradually restored some services and posted repeated updates during September saying engineers were continuing to work on a fix. Babylon and Injective were among networks for which restoration updates were specifically disclosed.
A final fix entered monitoring at 15:43 UTC on October 7 before Kraken declared the overall incident resolved later that evening through its official status page.
Kraken has not publicly explained a root cause detailed enough to establish which internal dependency linked the affected networks.
But the list is strikingly concentrated around the Cosmos and IBC ecosystem.
That makes the architecture question more important than the individual token names. If numerous chains share custody software, wallet infrastructure, node-management tooling or another common funding layer inside an exchange, one failure can potentially produce what looks externally like 23 separate blockchain problems.
The same shared-dependency question appeared during the Bitget laundering investigation, where multiple protocols became part of the same transaction path despite operating as independent systems.
“Operational” Does Not Mean Every Payment Path Is Healthy
The common lesson from the four incidents is that uptime dashboards can hide more complexity than a simple red or green status implies.
dLocal’s wider platform could remain operational while one Nigerian processor or bank failed. Tink could continue serving Spanish institutions while one Sabadell flow became unusable for most monitored users. PawaPay’s API could remain healthy while a Zambian mobile-money payout rail degraded. Kraken’s trading platform could continue running while deposits and withdrawals on a group of blockchains remained impaired.
That is increasingly how financial infrastructure fails.
Platforms are built on banks, card processors, open-banking gateways, mobile operators, blockchain nodes, custodians and routing providers. Each additional integration expands product coverage but also adds another boundary where service can degrade independently.
This distinction matters for merchants and traders because the practical failure may happen well after the application itself loads successfully.
A payment can reach the processor but fail at the bank. An Open Banking consent can work while the payment endpoint returns an error. A payout API can accept a request while the mobile-money operator cannot complete it. An exchange account can trade normally while a blockchain withdrawal remains unavailable.
The recent CMC Markets order-processing incident illustrated a similar problem in trading: platform availability and transaction availability are not the same thing.
Repeat Failures Are More Informative Than Individual Outages
The most important signals here are therefore the recurrences.
GTBank recovered and failed again three minutes later. Interswitch problems appeared across more than one payment company and on several recent dates. Sabadell’s new 90%-impact payment failure began less than 16 hours after Tink closed a separate long-running bank integration incident. Zamtel NFS has repeatedly degraded since late September. Kraken needed more than a month to fully close one broad funding event.
None of that proves systemic weakness across the companies involved, and it would be wrong to assign shared causes where providers have not done so.
But repeated failures expose something a single outage rarely does: where the fragile boundaries may sit.
For dLocal, the unanswered question is whether GTBank and Interswitch shared an affected processing route. For Tink, it is whether the latest Sabadell payment failure touched the same Open Banking/Redsys infrastructure as the earlier incident. For PawaPay, it is whether merchants have a practical alternative when Zamtel NFS repeatedly degrades. For Kraken, it is what common architecture connected so many Cosmos-adjacent funding gateways for 33 days.
Those are more useful questions than asking whether each platform was simply “up” or “down.”
Modern financial infrastructure increasingly fails one dependency at a time.
Johan Shamshad is a financial markets writer at Dave Finances covering cryptocurrencies, trading platforms, brokers, fintech, financial regulation, and developments across global markets. He previously worked at Gulf News, adding newsroom experience to his coverage of fast-moving financial and digital-asset markets.
His work focuses on identifying market-moving events, company developments, regulatory changes, product launches, and shifts in trading and financial infrastructure.
Johan contributes news and analysis designed to help readers understand not only what happened, but why a development matters and how it may affect the wider financial landscape.