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. Bank verification itself needed to become a reusable capability: something different products and partners could depend on without each creating its own verification logic or forcing every customer through the same journey.
The earlier implementation remained part of the legacy we had to support. I led the move toward a broader model with different assurance levels, multiple verification methods, country- and use-case availability, routing and fallback rules. The important boundary became clearer as we worked through it. Some parts of verification needed to stay stable across the platform; others needed to vary with the product asking for verification, the market the customer was in, and the operating conditions around that route.
“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.
One model had to work across very different markets
That distinction mattered even more at the scale we were working at. We were building bank verification for a footprint spanning more than 190 countries, with very different banking infrastructures and levels of market maturity. A route through a major international bank or financial institution could give us useful coverage across many markets. Another institution might connect us to a particular group of countries. In some places, the strongest customer experience came from a local provider.
Supporting that footprint could not mean integrating directly with every bank a customer might use. The product needed a relatively small set of broadly useful routes that could provide wide coverage, while still allowing specialized local methods to plug in where they materially improved the experience or filled a meaningful gap.
Those differences affected more than coverage. Stronger assurance could add customer friction. A technically available route could still be a poor operating choice if completion was unreliable or support overhead was too high. A partner might need broad geographic reach while a particular market justified a more local experience. Risk requirements could also change the evidence a consuming product needed. Those pressures all landed on the same verification capability.
The common part became the assurance contract: what level of confidence a product required, and what confidence had already been established for that account. The method used to establish it, where that method was available, the policy around offering it, and what happened if it failed could vary behind that contract.
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.
As the model expanded, I led the prioritization of which routes to add next. Broadly reusable connections usually came first because they extended the capability across more customers and markets. We then added narrower methods where they closed a meaningful coverage gap or offered a materially better customer path.
A specialized route could still require real discovery, integration work and operating rules. The difference was that once connected, it could fit into an existing assurance, availability and fallback model rather than bringing another partner-specific verification system with it.
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.
China made the architectural trade-off especially clear: we could 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
Technical implementation alone did not make a verification method appropriate to offer in every situation.
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.
The appropriate response, however, depended on what had failed.
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.
What the shared model made possible
The capability kept developing beyond the requirement that had triggered this work. It became the shared bank-verification capability behind marketplace and product flows operating across very different banking environments, provider landscapes and customer journeys.
Adding a verification route did not become trivial. A local provider could still require specific discovery, integration work and operating rules, just as a new global connection could introduce its own constraints. The difference was that those routes now had somewhere to fit. They could plug into the same assurance model, availability rules and fallback framework rather than becoming another verification product.
That materially reduced the amount of partner- and product-specific work needed as the capability expanded. Different products could ask for different levels of assurance while relying on the same underlying service. New methods could be introduced without every consuming flow learning their mechanics. Strong local methods could be used where they were valuable, while broadly available routes continued to carry more of the global coverage.
As coverage improved and more appropriate verification paths became available, customer eligibility increased from roughly 60% to about 90% globally.
The original partner requirement still had to be delivered. The more durable result was a product that could keep absorbing new markets, methods and consuming products without each one becoming another standalone verification system.
Open Banking and other forms of direct connectivity could become additional verification routes where coverage justified them, without changing the contract for products already 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 shared product model gave those differences explicit places to live. Products could rely on a stable assurance contract while methods, market availability, operating policy and fallback behavior evolved around it.
That separation made the capability useful across very different markets. A new route could improve coverage or customer experience without forcing every product depending on bank verification to change 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 historical product work from my time at Payoneer. Partner-specific requirements, provider details, internal systems, operating data, and sensitive implementation details have been generalized or omitted.