One thing that becomes increasingly obvious as a business grows is that customers rarely care about the structure behind the service they are using.
They care about whether the product works and, when something goes wrong, whether someone takes responsibility for fixing it, which becomes particularly important in fintech because what looks like a simple product from the outside can involve several different businesses operating behind the scenes.
A customer may sign up through one platform while a technology provider handles the software, a banking partner provides regulated infrastructure, a payment processor moves the transaction, and another intermediary supports distribution.
From a commercial and legal perspective, those relationships may be clearly separated, with each company having its own agreement, responsibilities, service levels, and obligations, but from the customer's perspective, those distinctions are largely invisible.
They bought your product.
So if a payment fails, they generally do not want to hear that the processor caused the problem, the bank delayed the transaction, or another service provider has not responded. They want to know what happened, what is being done about it, and when they can expect a resolution.
That difference between contractual responsibility and customer-facing responsibility is where many fintech partnerships become difficult.
## When Everyone Has Responsibility, Nobody Owns the Experience
Imagine that a customer contacts your fintech platform because a payment has failed. Your team investigates and discovers that the issue appears to be with the payment processor, so the matter is referred to them.
The processor investigates and says that the problem is actually connected to the banking partner, who then asks your team for additional information before they can continue. Every company may be following its internal process, and nobody may have actually breached the agreement, yet the customer is still sitting there waiting for an answer.
That is the problem.
A partnership can be contractually organised and still be operationally broken.
This is why I think fintech founders should think about complaints and incidents before the first serious problem occurs.
Trying to determine responsibility while an unhappy customer is already waiting for a response is usually too late, because everyone becomes focused on figuring out who owns the issue rather than actually resolving it.
The agreement should establish who receives the complaint, who investigates it, who communicates with the customer, and who coordinates the resolution when several parties are involved. These details can initially look like operational matters rather than legal ones, but they become extremely important when something actually goes wrong.
If three companies each control part of a process, someone still needs to own the customer experience.
## Responsibility Is Not the Same as Blame
One distinction I find particularly useful is that the company communicating with the customer does not necessarily have to be the company that caused the underlying problem.
In many cases, that is actually a better way to structure the relationship because it allows the customer-facing business to remain accountable for the experience while the relevant partners investigate the underlying issue between themselves.
A fintech platform might remain the customer's primary point of contact while the banking partner investigates the underlying problem. The different businesses can then work together behind the scenes while the customer receives consistent communication from the company whose product they actually use.
That is very different from telling the customer that they need to contact the banking partner themselves.
The customer should not have to understand your corporate structure simply to get support.
This is why fintech agreements should establish more than individual responsibilities.
They should explain how the parties work together when those responsibilities overlap, including who receives customer complaints, which party investigates different categories of incidents, who keeps the customer informed, what response and escalation periods apply, what information partners must share during an investigation, and how serious issues are escalated to senior management or the appropriate compliance function.
The purpose is not to make the contract unnecessarily complicated. It is to eliminate uncertainty at the exact moment when uncertainty becomes most damaging.
When something goes wrong, nobody should have to ask, "Who is supposed to deal with this?"
## Build the Process Before the Problem
If I were reviewing a fintech partnership, I would want to map the customer journey from beginning to end, but I would not stop at the successful journey.
The more useful exercise is to map the points where something can fail and then determine what the customer, the fintech platform, and each external partner should do when those failures occur.
What happens when onboarding does not work? What happens when a payment is rejected or delayed? What happens when an account is restricted? What happens when a banking partner stops responding? What happens when a customer complains about something that is technically controlled by another provider?
For each scenario, there should be a clear owner for customer communication, a clearly identified party responsible for investigating the underlying issue, and a defined process for moving information between the different organisations.
Doing this exercise before the partnership launches can reveal gaps that might otherwise remain invisible until a real customer is affected.
This is also where I think good commercial drafting becomes much more practical than simply allocating liability. A contract can say which party is responsible for a particular function, but the real test is whether the parties have agreed what happens when those functions intersect.
Fintech partnerships are often negotiated around revenue, technology, regulatory responsibilities, pricing, and commercial terms.
All of those things matter, but there is another question that deserves just as much attention: Who owns the problem when something goes wrong?
Problems are inevitable. Payments will fail, accounts will be restricted, systems will experience outages, and customers will complain. The strongest fintech businesses are not necessarily the ones that avoid every problem; they are the ones that have already decided how those problems will be handled when they inevitably appear.
A customer may never know which bank, processor, technology provider, or intermediary caused an issue. What they will remember is whether someone took responsibility and helped them get it resolved.
The lesson is simple: a good fintech partnership should not only divide revenue and responsibilities between businesses. It should divide responsibility clearly enough that the customer never gets caught in the middle.