When Parker Card collapsed, the company’s customers didn’t just lose access to a product. They lost access to their money, their cards, and their account history, all at once, because every layer of the business had been outsourced to a different vendor, and when financial pressure mounted, those vendors stopped cooperating with each other.
Alex Johnson, writing in Fintech Takes, put it plainly: “Fintech can be small, but fintech problems can be big.”[1] Parker Card was small. Its problems were not.
What actually happened at Parker Card
Parker Card was a corporate card and expense management startup. Like most fintechs of its generation, it was built on a stack of third-party services: a banking-as-a-service provider for the underlying accounts, a card network for issuing and processing, cloud infrastructure for the platform, and APIs connecting them together.
When the company ran into financial difficulty, the stakeholders in that stack did not pull together. They turned against each other. The BaaS provider had claims on the funds. The card network had its own contractual priorities. The cloud vendor had its own interests. And caught in the middle of the resulting disputes were the businesses that had been using the card, waiting to find out whether they could access their own money.
This is the musical chairs problem in modular fintech infrastructure. When everyone is cooperating, the music plays fine. When the music stops, customers discover there is no seat for them.
Why this pattern is not unique to Parker Card
Parker Card is the most visible recent example, but the underlying dynamic is structural. The European Supervisory Authorities’ first DORA major incident report, published in 2026, identified third-party dependency as the primary systemic risk factor for the EU financial sector.[2] That finding was based on observed incident data, not theory.
The fintech industry spent much of the 2010s and early 2020s celebrating the modular approach. Why build what you can buy? Stand up a card programme in weeks using Marqeta or Stripe Treasury. Handle KYC through an API call to a third-party provider. Run everything on AWS or GCP and treat infrastructure as a commodity. The approach genuinely does reduce time to market, and for a startup trying to reach product-market fit, that matters.
But the business case for modularity is made at the start of the journey, when capital is flowing and relationships are fresh. It is not remade at the end, when creditors are circling and every vendor is reassessing exposure. And that asymmetry is what makes the model fragile.
If your AI strategy is 100% dependent on a single API, you aren’t building a product, you’re renting one that could be turned off.
That observation was made in the context of AI tools, but it applies with equal force to payments infrastructure, card issuing, and every other layer of a modular fintech stack.[3] Dependency is dependency, whatever the domain.
The specific risk that firms underestimate
There are two failure modes in modular infrastructure. Firms think about the first one and ignore the second.
The first is vendor outage. The third-party API goes down, and your service goes with it. Firms plan for this. They negotiate SLAs, build redundancy, and maintain incident runbooks.
The second is adversarial disentanglement. The vendor relationship breaks down not because of a technical failure but because of a commercial or legal dispute, and the vendor stops cooperating in the unwinding. This is what happened to Parker Card’s customers. The vendors did not fail technically. They became adversaries.
There is no SLA for adversarial disentanglement. It is not a technical problem. It is a governance and contractual problem, and most fintechs sign their vendor agreements in the optimism of the early stage, without modelling what those agreements look like when the commercial relationship sours.
Airwallex has built its competitive position on holding a large portfolio of regulatory licences and local payment network integrations across multiple jurisdictions, according to a 2026 analysis by Digital Applied.[4] Its moat is not algorithmic. It is structural. Owning the licences and the network relationships means that in a dispute, Airwallex holds the cards. A fintech renting all of those relationships from a single BaaS provider holds none.
What firms outside fintech should take from this
If you run an advice firm, a wealth management business, or any regulated professional services firm that has built workflows on top of third-party tools, the Parker Card story is not someone else’s problem.
The same structural dynamic applies to your AI tooling, your CRM integrations, your client portal, and your document management stack. The vendors you depend on are making their own commercial calculations. When those calculations change, because they pivot their product, because they are acquired, because they run out of runway, your options are constrained by whatever exit terms you negotiated (or didn’t) at the start.
Anthropic’s acquisition of Stainless, a third-party SDK generator used by many development teams, illustrates the subtler version of this risk. Neutral infrastructure can become a competitive pressure point when it is acquired by a direct competitor in your market.[5] You did not sign up for that exposure. It arrived through an acquisition you had no input on.
What a safer approach looks like
The antidote to modular dependency is not to stop using third-party tools. That is neither practical nor the right lesson. The antidote is structured thinking about what you own, what you rent, and what happens when the rental agreement is terminated by the other side.
A few principles that hold up:
First, map your dependencies honestly. Not just the direct ones. The API you call may itself depend on a cloud provider, a payment network, or a data vendor. Draw the chain out to at least two layers and ask what happens at each node if the relationship becomes adversarial.
Second, identify your non-negotiables. Which parts of your operation require continuity regardless of what any individual vendor does? Client data, transaction records, regulatory audit trails. These cannot sit exclusively in a vendor’s custody without a clear extraction and portability agreement in place.
Third, build for the ‘Safe Failure’ scenario. The fintech-takes framing for this is the “break-glass” procedure: a standardised plan for what happens to customers if one partner fails.[1] That plan must be agreed and documented before the failure, not improvised during it. For regulated firms, this overlaps directly with DORA’s operational resilience requirements.
Fourth, treat vendor contracts as resilience documents. The SLA covers uptime. The resilience document covers exit: data portability, notice periods, dispute resolution, and what the vendor is obligated to do for your clients during an unwinding. If your contracts do not address these questions, that is the gap to close.
Fifth, take the multi-provider principle seriously. Abstracting AI or infrastructure dependencies through an interface layer, maintaining tested alternatives, and documenting the quirks of each provider[6] takes more upfront effort than signing with the first vendor who can do the job. It also means you are not renegotiating from a position of zero leverage when circumstances change.
The structural lesson
Parker Card’s collapse will not be the last of its kind. Margin compression is forcing application-layer startups across fintech and AI to pivot or fail, often with little warning to the customers who built workflows on top of them. The principle is direct: firms that own their critical infrastructure maintain margins and avoid capability traps that dependency creates. The same logic applies to payments, data, and any other critical operational layer.
The firms that will weather vendor instability are not necessarily the ones with the most sophisticated technology. They are the ones that modelled what happens when the phone stops being answered, negotiated the right terms before it mattered, and designed their operations around the assumption that any third-party relationship can end on someone else’s schedule.
For a firm thinking through where its own vendor exposure sits, and what the realistic options look like given its size and resource constraints, a discovery call with Cordrey Consulting is a practical place to start.
This article is for informational purposes only and does not constitute regulated financial advice or a compliance opinion. Consult a qualified compliance professional for advice specific to your firm.
This article does not constitute legal or regulatory advice. DORA obligations apply to regulated financial entities and their ICT third-party providers. Consult a qualified adviser for your firm’s specific requirements.
Sources
[1] Johnson, A. (2026) ‘Parker Card collapse and the musical chairs problem’, Fintech Takes. [Cited for the Parker Card narrative and the ‘Safe Failure’ framework.]
[2] EBA, EIOPA and ESMA (ESAs) (2026) ‘ESAs publish first report on DORA major ICT-related incidents’, European Supervisory Authorities. Available at: https://www.esma.europa.eu/press-news/esma-news/esas-publish-first-report-dora-major-ict-related-incidents [Cited for third-party dependency as primary systemic risk factor.]
[3] Zen van Riel, AI Engineer Blog (2026) ‘Anthropic Pentagon dispute: AI engineer implications’, Zen van Riel. Available at: https://zenvanriel.com/ai-engineer-blog/anthropic-pentagon-dispute-ai-engineer-implications [Cited for the single-API dependency observation.]
[4] Digital Applied (2026) ‘Airwallex agentic finance AIRI: autonomous money 2026’, Digital Applied. Available at: https://www.digitalapplied.com/blog/airwallex-agentic-finance-airi-autonomous-money-2026 [Cited for Airwallex’s licence portfolio and payment network integrations as competitive moat. Specific counts of licences and integrations should be verified against Airwallex’s own regulatory disclosures at https://www.airwallex.com/uk/legal/licences before publication, as these figures change as the company enters new markets.]
[5] Zen van Riel, AI Engineer Blog (2026) ‘Anthropic Stainless acquisition: SDK infrastructure risks’, Zen van Riel. Available at: https://zenvanriel.com/ai-engineer-blog/anthropic-stainless-acquisition-sdk-infrastructure [Cited for the risk of neutral infrastructure becoming competitive through acquisition.]
[6] Zen van Riel, AI Engineer Blog (2026) ‘Multi-provider imperative and AI engineer implications’, Zen van Riel. Available at: https://zenvanriel.com/ai-engineer-blog/anthropic-pentagon-dispute-ai-engineer-implications [Cited for the multi-provider abstraction pattern.]