Some product problems announce themselves as platform problems. Others arrive looking like a checkbox. Bank verification was closer to the second kind.
The initial requirement came through a major marketplace integration and was solved largely as a tailored implementation for that partner. About a year later, another global marketplace arrived with broader geographic coverage and more evolved verification requirements. I came into the work at that point.
The requirement was familiar enough to resemble the earlier one, but different enough that extending the partner-specific solution no longer made much sense. More importantly, verification could gate onboarding or access to a service. It was not always a background check that could finish whenever it finished.
That changed the product question.
We were no longer asking how to satisfy one marketplace’s requirement. We needed to define bank verification itself as a reusable capability — one that could support different business needs without forcing every customer through the same process.
The earlier implementation became part of the legacy we had to support. From there, I led the extension into a broader model: multiple verification methods, different levels of confidence, country-specific availability, routing and fallback rules, and a structure that could serve more than one partner or product.
“Verified” was hiding more than one question
A bank account can be verified in different senses.
For one use case, evidence that the person can access the account may be enough. Another may require stronger evidence connecting the account to its owner. Treating both as the same verified / not verified state creates a bad choice: either everyone goes through the strongest process, adding unnecessary friction, or some products accept evidence weaker than their requirements.
The product decision was to separate the confidence established from the method used to establish it.
A product depending on bank verification could then ask: What level of assurance do we already have for this account, and is it sufficient for this use case?
That mattered because stronger verification was not free.
Document verification could require finding an acceptable bank document, uploading it, waiting for checks, and sometimes trying again. Payment-based verification removed the document requirement but introduced a different journey: wait for small payments, identify them, then return and confirm the amounts. Other methods required very little customer action but existed only in certain markets.
The goal was not to choose the strongest method every time.
It was to establish enough confidence for the product need, using the best viable path for that customer and market.
The method is not the requirement
We did not start from scratch.
Bank-statement verification already existed. We brought it into the broader process, refined aspects of automated document checking, and kept it available when it was the right option.
We also developed penny-drop verification: sending small randomized payments to a bank account and asking the account holder to confirm the amounts. We deployed it across many countries where local banking infrastructure and regulation made the method viable.
The two experiences were very different. Document verification could provide strong evidence but depended on the customer having a usable document. Penny drops removed that burden but depended on the payment reaching the account and the customer returning to complete confirmation.
Neither was universally better.
Open Banking pointed toward another route. Where direct bank connectivity was available and reliable enough, it offered the prospect of establishing useful account evidence with relatively little customer effort. But coverage and maturity were still too uneven for it to become the global answer.
The important part was keeping the method separate from the business requirement.
A product consuming bank verification should not need to know whether a document, test payment, direct bank connection, or local provider is the best way to establish confidence in a market. It should know what assurance it needs. The verification capability can then choose among the eligible routes.
Local methods, global model
China made the value of that separation especially clear.
There, locally licensed verification providers could verify bank-account information quickly and with very little customer effort. From both a customer and product perspective, it was one of the better options available to us.
Equivalent coverage usually did not exist elsewhere.
A colleague on the banking side managed the provider relationship. I led the product discovery and integration: understanding what the provider could reliably establish, determining how that evidence fit into the broader verification model, and taking the product integration through delivery.
The challenge was not how to work around China. It was how to take advantage of a strong local method without designing the global product around an option unavailable in most markets.
So the common contract remained the assurance we could provide. The route to that assurance could vary locally.
That let us use a strong market-specific capability without forcing every product consuming bank verification to understand how the result had been produced.
Availability became an operating capability
A verification method being technically implemented did not mean it should always be offered.
I owned the initial product rules around method availability by country and use case. Those rules were shaped with Operations, Risk, GTM, Banking Relations, Engineering, and other relevant teams, taking into account banking infrastructure, regulation, customer experience, operational burden, fraud exposure, and provider reliability.
We also had to care about what happened after launch.
If a theoretically suitable method produced too many failures, took too long, or regularly pushed customers into support, technical availability was not enough. When verification gated onboarding, a rejected document, delayed payment, or unnecessary retry could leave someone stuck mid-process.
Conditions could also change. A method might need to be disabled because of suspected abuse. A provider or banking interface could develop a problem. The best option for a market could temporarily stop being one.
The initial rules therefore evolved into something more useful than product decisions frozen in code.
Over time, the capability became configurable enough for Operations and business teams to steer which methods were available in the situations they managed, within product-defined boundaries. They did not need a new engineering project every time an operating condition changed.
The model separated three questions: whether a method existed, whether it should currently be offered, and whether the evidence it produced was sufficient for the product asking for verification.
Once those controls existed, the product could adapt without changing its underlying contract.
Failure is part of the product too
That flexibility became especially important when verification did not work the first time, because “verification failed” covered very different situations.
A customer might not have the required document, or the document might repeatedly fail checks. Penny-drop payments might be rejected by the receiving bank. They might arrive, but the customer could enter the wrong amounts or never return. A provider might be temporarily unavailable. A method might have been disabled because of risk or operational concerns.
For a customer whose onboarding depended on verification, the immediate consequence was the same: they were blocked.
But the product response should not be.
We modeled the criteria and settings that determined what could happen next: which alternative methods were eligible, whether another route could be offered, and when the case needed different handling.
Our first version was deliberately conservative.
Payment-based verification created a particular abuse concern. We did not want repeated failed attempts to trigger an unlimited sequence of small payments, so the MVP restricted fallback more tightly than the later product.
That protected one side of the system, but legitimate customers could also run out of useful options.
As we gained operating experience, we broadened the fallback model. Account holders could increasingly choose among the verification methods actually available to them instead of being forced repeatedly through a route that was not working.
That could reduce the time a customer remained blocked and keep more cases out of manual handling. But unrestricted retries could create new risk.
The product had to hold both.
From one requirement to a shared capability
The earlier marketplace implementation remained something we had to support, but the broader model emerged because the next requirement showed that continuing to build partner-specific verification logic would not scale.
The capability developed incrementally and went well beyond the initial MVP. It became the live bank-verification capability supporting those marketplace flows across markets with very different banking infrastructure, provider availability, and operational constraints.
The required partner rollout was delivered, but the more durable result was that the next requirement no longer needed to become another verification system.
Different products could ask for different levels of assurance while using the same underlying capability. New methods could be introduced without every consuming flow understanding their mechanics. Strong local methods could be used where available. Operations could adjust availability as conditions changed. When one route failed, the product increasingly had another sensible path.
Open Banking and other forms of direct connectivity could then become additional verification routes where coverage justified them, without changing the contract for products relying on bank verification.
What I took from it
“Verify the bank account” sounds like one action.
In practice, it contained several product questions: What assurance does this use case require? What evidence do we already have? Which methods are available here? How difficult are they for the customer? How reliably and quickly do they complete? And what happens when the first choice fails?
There was no universally best verification method.
Documents could be the right answer in one situation and unnecessary friction in another. Penny drops could expand coverage but introduce waiting and confirmation. A local provider could deliver an excellent experience but only in the market it served. A newer connectivity method could be promising without yet having enough coverage to carry the global product.
The platform decision was not to hide those differences. It was to give them somewhere to live.
The confidence requirement, available methods, market policy, and fallback behavior became separate parts of the model. One could evolve without forcing every product depending on bank verification to evolve with it.
And as the capability matured, some of those product decisions became operating controls that the teams running the business could use directly.
For me, that was the product work hiding inside what initially looked like a checkbox.
This article describes a historical product case from my time at Payoneer. Partner-specific requirements, provider details, internal systems, operating data, and sensitive implementation details have been generalized or omitted.