When Wise Makes It… Not So Wise: A Story About Broken APIs, Frustrating UX Changes and the Pitfalls of OpenBanking

Running a digital business in 2025 means connecting the dots between a dozen third-party services, each with their own quirks, bugs, and unexpected behavior. Sometimes these services make improvements. Sometimes, they make decisions. And every once in a while, those decisions have unintended consequences that ripple downstream to companies like ours — and to our customers.

This is one of those times.

Recently, Wise introduced a small but incredibly disruptive change in their OpenBanking connection flow that is quietly but significantly breaking bank account reconnections for thousands of users.

Let me explain.

What Changed (And Why It’s a Big Deal)

Until now, when one of our customers connected their Wise account through our dashboard using the OpenBanking flow via GoCardless, all balances in their multi-currency account were pre-selected by default.

This is the expected behavior. The user selects their account, hits next, and all the currency balances (EUR, USD, GBP, etc.) are included.

But now, Wise changed this behavior. No balances are selected by default. The user must tick each one manually. Seems harmless, but it is not.

Most users are lazy, they are busy, or simply don't have time to spend a lot of time reconnecting their bank accounts. They click next, selecting one account at most. As a result, only one balance gets connected. Our accounting team is left wondering why transactions are missing, only to realize much later that the reconnection is incomplete.

What follows is a frustrating loop:

• The accountant asks the customer to reconnect properly.
• The customer replies angrily: “But I already reconnected my account!”
• Time is lost, data is missing, and the whole workflow breaks down.

Violations of OpenBanking, Data Correctness, and Basic API Principles

The UX change in Wise’s connection flow is frustrating, yes — but it’s only the tip of the iceberg. The deeper problem is something far more serious: Wise repeatedly violates data correctness and integrity principles.

OpenBanking was built on the idea of structured, predictable, precise financial information — not guesswork. But working with Wise’s API often feels like reverse‑engineering a puzzle that keeps changing shape.

1. Wise Assigns the Same Transaction ID to Completely Different Transactions

This is one of the most egregious and recurring issues.

Wise frequently returns multiple transactions — with different dates, amounts, and booking times — using the exact same transactionId. Below is a real example (anonymized):

{
  "transactionId": "1234567890",
  "bookingDate": "2025-05-26",
  "bookingDateTime": "2025-05-26T14:12:35.110491Z",
  "transactionAmount": {
    "amount": "-40000.00",
    "currency": "EUR"
  },
  "creditorName": "John Smith",
  "creditorAccount": { "iban": "XX1234567890" },
  "remittanceInformationUnstructured": "Some remittance info",
  "additionalInformation": "TRANSFER-1234567890",
  "proprietaryBankTransactionCode": "TRANSFER",
  "status": "booked"
},
{
  "transactionId": "1234567890",
  "bookingDate": "2025-06-03",
  "bookingDateTime": "2025-06-03T13:03:02.409548Z",
  "transactionAmount": {
    "amount": "39870.76",
    "currency": "EUR"
  },
  "remittanceInformationUnstructured": "Some remittance info",
  "additionalInformation": "TRANSFER-1234567890",
  "proprietaryBankTransactionCode": "TRANSFER",
  "status": "booked"
}

These are not the same transaction. They are not even variations of the same transaction. They are separate financial events occurring on different dates, in different amounts, with different effects on the account balance.

Yet Wise assigns both the same transaction ID — 1234567890.

Wise “explains” that they consider these entries to be “parts of the same transaction.” But OpenBanking is not supposed to be metaphoric. It is not a story-telling format. It is data. Data must be unambiguous.

If two entries have different amounts and different timestamps, they must have different transaction IDs. That is a foundational rule of any database, ledger, or API.

Even worse: Wise used to assign the same transaction ID to the fee for one of these transactions as well. So there were three different transactions with the same transaction ID. Only after repeated complaints did they start prefixing fee entries with something like FEE-1234567890 — itself a hack that reveals the absence of a strict, enforced standard.

Why This Is a Critical Problem

Our OpenBanking partner does provide a unique internal ID for each entry, but we cannot rely on it — because we reconcile transactions from multiple sources (banking APIs and uploaded bank statements). A transaction coming from OpenBanking and the same transaction coming from a CSV statement must match, not be treated as duplicates.

If a provider like Wise reuses transaction IDs arbitrarily, then reconciliation becomes guesswork. Accounting and financial compliance cannot be based on guesswork.

2. Missing Transactions Entirely: The Case of Wise Investment Accounts

Wise also offers so‑called “investment accounts” — essentially savings/investment products where your balance grows with returns. In the Wise dashboard, users see these returns as incoming transactions.

But in the API? There is no transaction. Just a mysteriously increased balance. This means:

• The balance changes…
• …but no transaction explains it (?).

This breaks every rule of accounting and API design. A balance cannot change without a corresponding entry. Period. Ever.

Because Wise provides no transaction record for these returns, our system must detect this anomaly and then:

• Ask the customer whether they’re using a Wise investment product.
• If yes, mark the account as an “investment account.”
• And — this part pains me — generate “ghost transactions” to keep balances and ledgers coherent.

Yes. We have to invent transactions because Wise doesn’t provide them. It is as terrible as it sounds.

3. These Are Not Isolated Incidents — Fintech APIs Are Some of the Worst Offenders

We experience similar issues regularly not only with Wise –even though they are the main offender–, but also with providers like PayPal, Stripe, and others who:

• Reuse transaction IDs
• Skip or hide transactions.
• Omit required fields
• Mislabel references
• Fail to provide consistent timestamps
• Break their own documentation
• Change API behavior without notice

The Problem With OpenBanking: When “Standards” Are Just Suggestions

The OpenBanking initiative was supposed to unify the way financial data is shared across banks, fintech platforms, and service providers. In theory, it provides a standard interface for accessing banking information across Europe and beyond — based on the UK’s Open Banking Standard and further formalized in technical documents like:

• The Open Banking Read/Write API Specifications
• The PSD2 RTS (Regulatory Technical Standards)
• ISO 20022 and ISO 8583 messaging standards for financial data

But unfortunately OpenBanking doesn’t work like a true, enforced protocol. It functions more like a loosely agreed-upon guideline.

There is no governing body or enforcement mechanism ensuring that all banking providers implement the APIs in a uniform way – or if there is, they're not doing a great job. That means banks are free to interpret — and often misinterpret — key aspects of the standard.

No Standardized Field Definitions or Requirements

Even something as simple as a transaction reference is a mess. Some banks include it; others omit it. In some cases, the “reference” field is not a reference at all, but a vague internal memo, a processor ID, or worse — a meaningless alphanumeric string. This makes it incredibly hard for accounting or reconciliation software to extract meaningful information.

We need to go beyond loose recommendations. We need:

• Clear field definitions and mandatory data requirements.
• Enforcement of semantic consistency in key fields like transactionId, reference, amount, and timestamp.
• A precise definition of what is required in a complete transaction object, and what must be unique.

UI/UX Chaos: A Missing Standard for Authorization Flows

Beyond the API itself, OpenBanking also leaves the user experience completely undefined. Banks can create wildly different authorization flows, interfaces, and logic. This inconsistency introduces serious friction for users and breaks product expectations.

Take Wise again: they recently changed the way users connect accounts. Now, currency balances are not selected by default — which is unlike almost every other bank integration. For an average user who expects all balances to be synced (like before), this leads to confusion, missing data, and accounting issues on our side. All because a checkbox was left unselected by default.

Most users don’t understand what “balance selection” even means — they just want to connect their bank and move on. We shouldn’t be designing APIs and flows that punish the busy user for not reading every checkbox. That’s poor UX design and a broken implementation of OpenBanking principles.

A Call for Real Standards and Enforcement

OpenBanking has great potential — but right now, it’s a wild west of interpretations, half-baked implementations, and zero accountability.

If we want this ecosystem to work, we need:

• Stricter guidelines that are enforceable — not just “good practices”
• A governing body or certification process to ensure cross-provider consistency
• Unified UX patterns for things like balance selection, account permissions, and transaction history
• A developer-centric standard that doesn’t tolerate ambiguity in core fields like transaction ID or reference

Until then, companies like ours are forced to resort to defensive programming, error recovery hacks, and awkward user prompts — just to work around poor or inconsistent implementations by major players.

What Are We Doing?

Let me be clear: we’ve already notified the involved parties of the problem (as we've done with all previous API issues). As GoCardless clients and partners, we were directed to Wise since the issue originates from their API and OpenBanking integration, not GoCardless.

That said, we’re not naïve. We know that in most cases, these support requests go nowhere. We’ve been down this road many times with providers who rarely consider the downstream impact of their changes. So we are taking matters into our own hands through defensive programming and proactive design.

Here’s what we’re implementing, right now:

• An explanatory animation showing how to manually select all balances when connecting a Wise account — to make it visually obvious and idiot-proof.
• An updated FAQ (with the video embedded) that emphasizes — in bold — that all balances must be selected manually.
• A new tool for accountants: They can flag a connected Wise account as needing reconnection due to incomplete balances. This sends an email to the customer explaining what went wrong and what to do.
• A reconnection checker: If we detect fewer balances than before, the customer gets an alert like:

“We noticed you may have missed some balances. Previously we had data about the following balances: EUR (3), USD (2), and GBP (1). Now we only received EUR (2) and USD (1). Please reconnect and select all balances manually.”

• A dashboard popup when connecting or reconnecting Wise accounts that clearly explains the change and requires the customer to confirm:

“Make sure to select all balances!” “Wise now requires you to manually select your balances. To give us complete financial data, please make sure you tick every balance before continuing.”

We’re fast-tracking these fixes because we know this is already affecting customer experience and accounting workflows — and it will only get worse.

A Final Word: When OpenBanking Becomes OpenGuessing

So yes, we’re frustrated. As a bootstrapped startup, we don’t have the luxury of blaming others and moving on. We build workarounds, patch holes, and defend our code from external nonsense, because that’s the only way to survive. But that's far from ideal.

And when someone breaks things that used to work just fine, we’ll call it out — constructively, but clearly.

As I said before, “Honest Disruption” is one of our core values at Companio. That means being willing to say: “This could be better.” And then doing something about it.

👉 Are you a Wise or OpenBanking engineer? We’d love to talk. (I would honestly love to be hired by Wise to audit their API and make sure it becomes a correct, compliant, and reliable API).

👉 Are you a Companio customer having trouble with bank connections? Don't worry, we'll do our best to make it work for you. We always do.

👉 Are you tired of APIs that look great in theory but break in real life? You’re not alone.