Three parties, and brokers only see one
Bank data passes through three hands before a broker sees it: the client's bank, our open banking provider, and our platform. When anything goes wrong at any step, the broker sees it in our product, so to them it's our bug.
I came to this support work without a lending background and without a local bank account to test the flows myself. That shaped my method: I couldn't reproduce problems on my own, so I learned to rebuild them from the evidence brokers and the provider could give me.
The first week: keep brokers informed while engineering fixed it
A large incident right after launch
Open banking went live in late May, and a large incident followed within days. Our backend lead shipped the hotfix seven days after go-live. My part was the other side of that week: the brokers.
During that week brokers were mid-application with real clients. Silence would read as “they don't know”. A blocking alert would stop work that still mostly functioned.
What I did: triaged incoming tickets, passed engineering the patterns and evidence from them, and designed a dismissible banner that named the problem, said what still worked, and promised the next update.
Why statements went missing
The most common ticket after launch was “my client's home loan statement isn't there.” The connection worked, other accounts came through, and nothing showed an error.
Comparing tickets, I found the pattern. A statement only arrives if its whole cycle falls inside the window the client consented to. Transaction accounts produce statements every month. Some home loans produce one every three to six months, so a three-month window can miss it entirely.
I turned that into a short guidance article in brokers' terms: why it happens, how to tell, and two ways forward. Start a new application with a longer window for that client, or ask the client to download the statement from their internet banking.
Defending a 93-day default
Longer isn't better
Once brokers learned that longer windows caught more statements, the obvious request was to make every window long. I argued to keep the default at 93 days.
Lenders need about three months of history for most applications. A year of data by default would expose older parts of a client's financial life that nobody needs, and that the client may not expect to share.
Where it landed: 93 days stays the default. The allowed range now goes up to 365 days, so brokers can choose a longer window for the clients who need it.
Enough for most lenders. Choose up to 365 days if your client has a home loan with long statement cycles.
Bank-side bugs that looked like ours
Brokers can't see past our screen, so I learned to separate what we could fix from what we could only explain.
| What brokers saw | Actual cause | What we did |
|---|---|---|
| No running balance on transactions | One bank's API doesn't provide it | Explained the limit; client downloads the official statement meanwhile |
| Negative closing balances overnight | A faulty bank release, fixed the next day but not retroactively | Told brokers exactly which connections needed a fresh reconnect |
| Statements without the official trust mark | Banks outside, or still joining, the open banking framework | Clear wording on what that means for lenders |
| “Duplicate” files per account | A statement and a transaction file, by design | Guidance article, so brokers stopped raising it |
| Old data after a client reconnects | Summaries use the first connection only | Documented the limit and a workaround; raised it as a product issue |
The words brokers and clients saw
A text message clients would trust
Clients receive a text asking them to connect their bank. To a cautious client, that looks exactly like a scam. The message had to fit one SMS segment, use only characters every phone shows correctly, and end with a sender clients could check.
I applied the same thinking to every reply brokers got from support: no internal environment names, no vendor names, and requests phrased as requests, not instructions.
A playbook, not heroics
Most tickets fell into a few shapes, so I wrote down how to handle the most common one: “it should have worked, but it didn't.”
Name the most likely cause from past tickets.
The single answer that confirms or rules it out.
Ask for what proves it: a screenshot, an application number.
Never imply the broker or client did it wrong.
A way to keep the application moving today.
What we do next if the hypothesis is wrong.
For problems caused by a bank or another vendor, a second rule set applies: confirm the issue is known without promising a date, commit to a concrete next step, and ask the broker's consent before sharing any client data outside the company.
Every recurring ticket also goes back to the product backlog. Requests like shared team email logins aren't support questions; they're signals about how broker firms actually work.
Where my manager and I disagree
One limitation kept coming back: when a client reconnects their bank, summaries still show data from the first connection. We agree it needs fixing. We disagree on how.
I designed the flow and requirements for my option, wrote up both with their trade-offs, and left the call with my manager. It's still open. Either way, the team will build from a written comparison instead of a hallway opinion.
Decisions I'd defend, and what they cost
A dismissible banner during the incident
Honest about the problem without stopping brokers' work.
Some brokers dismissed it and asked anyway.
Keep 93 days as the default
Enough for lenders, nothing more of the client's history.
Brokers with long-cycle home loans need an extra step.
Explain bank-side issues instead of absorbing them
Brokers get an accurate picture and a workaround.
We can't promise a fix date for someone else's system.
Write the playbook down
Anyone on the team can answer the common cases the same way.
Time spent writing instead of closing tickets that week.
Outcome
What I'd do next
- Warn brokers in the product when the chosen window is shorter than a client's loan statement cycle, before the request goes out.
- Add a simple status note for known bank-side issues, so brokers can check before raising a ticket.
- Settle the reconnect question with a small test: show both options to a few brokers and measure which one they trust.
What I learned: when your product depends on other companies' systems, trust comes less from never failing and more from being the one who explains clearly what happened and what to do now.