What Changes When the Company That Builds the Pipes Doesn't Hold the Water

The regulatory question that recurs in virtually every fintech compliance review is not "is this legal?" — it is "who is responsible for what?" The more clearly that question can be answered, the more efficiently the regulatory system functions: fewer enforcement ambiguities, cleaner audit scopes, lower compliance overhead for all parties. When the company that builds financial infrastructure also holds assets, controls transactions, or exercises discretion over outcomes, the responsibility question gets complicated in ways that burden regulators, banks, operators, and consumers simultaneously. Clear role separation eliminates that complication — and the benefits that follow are systemic, not marginal.

The Custodial Spectrum — Why Not All Infrastructure Is Equivalent

The custodial–non-custodial distinction in financial infrastructure is not binary. It is a spectrum, and the regulatory and banking implications of each position on that spectrum are meaningfully different from one another.

At one end sits full custody: the entity holds client assets, executes transactions on their behalf, manages balances, and bears the full suite of regulatory obligations that attach to financial intermediation — licensing, capital requirements, AML/KYC programmes, user fund protection, transaction monitoring. This is the model of an exchange, a bank, or a licensed custodian. The regulatory burden is highest, and banking partners apply the most scrutiny to counterparties in this category.

Pooled or partial custody occupies the next position. The entity aggregates client assets in shared wallets, may not hold them individually attributable to specific clients, but still exercises control over those assets and their movement. Most virtual asset service provider definitions in active regulatory frameworks capture this position.

Software with retained admin keys is the contested middle ground. The entity deploys smart contracts or hosted infrastructure and retains upgrade privileges, pause functions, or admin access post-deployment. Contractually, it may agree never to use those capabilities. But the existence of the technical capability is treated by several regulatory bodies as a form of ongoing control — and banks' AML systems often cannot distinguish between contractual limits on technical capability and architectural absence of technical capability.

At the other end sits truly non-custodial infrastructure: no keys, no admin privileges after deployment, no discretion over contract execution. The relationship to the deployed programme is identical to an ERP vendor's relationship to a bank's accounting systems — the vendor built the system, but the bank operates it, and the vendor has no ongoing access to the bank's accounts. This is the position where the regulatory and banking implications shift most dramatically.

Banking Access and the De-Risking Problem

Correspondent banking de-risking — the practice of banks withdrawing services from entire categories of customers to manage AML compliance exposure — has disproportionately affected fintech and crypto-adjacent companies since approximately 2015. BIS analysis published in 2021 documented a sustained decline in the number of large global banks offering correspondent services across multiple regions, with emerging market fintech operators reporting the sharpest reductions in access.

The root cause is categorical risk assessment. Bank AML systems are calibrated to flag companies with virtual asset or crypto exposure as elevated risk — regardless of the specific nature of that exposure. A company that builds loyalty infrastructure using smart contract technology may be categorically grouped with companies that operate exchanges, custody user funds, or process transaction settlements, even though the business models are entirely distinct.

The re-categorisation argument for non-custodial infrastructure providers is straightforward: the AML risk profile of a company with no custody, no transaction processing, and no asset-linked revenue is indistinguishable from any other enterprise software vendor. Its revenue is consumption-based. Its payments are technology licensing fees. Its own AML surface area — the transactions and relationships that its AML programme needs to monitor — consists of its employee and vendor relationships, not the assets of its customers' customers.

Banks whose compliance systems can make this distinction maintain more accurate correspondent relationships and provide services to a broader and more legitimate set of technology companies. Banks that cannot are applying a blunt categorical filter that treats architectural differences as irrelevant. As regulatory guidance in the major fintech jurisdictions increasingly distinguishes between custodial intermediation and non-custodial infrastructure, the case for re-categorisation strengthens — and the banks that update their frameworks first will serve a broader and more accurately assessed client base.

Regulatory Clarity and Examination Efficiency

When roles are clearly separated, regulatory examination scope is unambiguous. This is a benefit to every participant: the software vendor, the operator, the regulator, and the legal counsel involved on all sides.

The software vendor is examined as a technology supplier. The examination covers information security, data protection, business continuity, third-party risk, and software quality assurance. It does not cover asset custody, transaction monitoring, user fund protection, or AML programme adequacy — because the vendor does not perform those functions. The examination scope is narrow, well-defined, and consistent with the standard IT audit framework applied to any enterprise software provider.

The operator is examined as a financial service provider. The examination covers their KYC/AML programme, sanctions screening controls, user onboarding procedures, transaction monitoring, capital adequacy, and consumer protection obligations. The vendor's activities are clearly outside this scope. The operator's compliance team does not need to document the vendor's regulatory position as part of their own examination — the vendor's status is clean, documentable, and consistent across jurisdictions.

The alternative — blurred roles — produces overlapping examination scope with ambiguous jurisdictional boundaries. Which regulator covers a vendor's activity in a programme deployed across three jurisdictions? What happens when the vendor retains admin keys that technically allow intervention, even if no intervention has occurred? These questions consume regulatory resources, generate legal disputes, and increase compliance costs for all parties. Clear role separation converts those questions into non-issues.

Consumer Protection — The Clear Liability Chain

Consumer protection in financial services depends on a foundational principle: the consumer must have a defined counterparty with known obligations. When something goes wrong — a disputed transaction, a wrongly blocked account, an incorrect balance — there must be an identifiable party with the regulatory obligation to respond and make the consumer whole.

In a blurred-role architecture, this principle is compromised. The consumer interacts with an operator brand whose underlying infrastructure is operated by a technology vendor that has undisclosed technical capabilities. If a problem arises, the question of who bears responsibility is genuinely ambiguous. The operator may point to a technical limitation. The vendor may point to contractual restrictions on its role. The consumer is left navigating a dispute between two parties, neither of whom has fully assumed accountability.

In a clear-role architecture, the liability chain is unambiguous. The operator governs the deployed contract. The operator has the financial service relationship with the user. The operator's terms define the user's rights and the redress process. The vendor's role is explicitly bounded to software provision. "We just build the tools" is not available as a defence to the operator — because the operator explicitly assumed governance of the deployed programme at the moment of deployment. Accountability is structural, not contractual.

This clarity benefits the vendor as well. Its liability is bounded to the software it provides and the quality of that software. It does not extend to the downstream financial outcomes of every programme that uses its infrastructure. This is the standard technology supplier liability model, and it is the model that enables vendors to serve multiple operators across multiple jurisdictions without assuming the aggregated financial risk of all programmes simultaneously.

Cross-Border Interoperability — Jurisdiction-Neutral Infrastructure

Non-custodial infrastructure is jurisdiction-neutral by design. The smart contract executes its encoded logic regardless of where the operator is domiciled, where the members are located, or which regulatory framework applies to the programme. The software vendor does not provide financial services in the operator's jurisdiction — it provides software that the operator deploys and governs within their own regulatory perimeter.

This has a concrete consequence for global deployment. The software vendor holds one technology company licence in its home jurisdiction. It serves operators in the UAE, Singapore, the EU, the UK, and any other jurisdiction without requiring separate regulatory approvals in each — because it is not in the business of providing financial services in those jurisdictions. The operator in the UAE assesses their own regulatory obligations under the applicable UAE frameworks. The operator in Singapore does the same under MAS frameworks. The operator in the EU assesses their obligations under MiCA and relevant national law. Each operator navigates their own local requirements; the vendor navigates none of theirs.

The alternative — a custodial vendor serving global operators — requires a multi-jurisdictional licensing stack. Each jurisdiction in which the vendor's custody activity reaches users may require its own regulatory authorisation. Conflicts between those requirements (data residency, capital, user fund segregation) create structural barriers to deployment and compliance overhead that compounds with each new geography. Non-custodial infrastructure collapses this complexity into a single technology licence and a well-defined operator responsibility model.

The Practical Takeaway — Why This Architecture Is Good for the Industry

The systemic case for clear role separation is stronger than the individual case for any one vendor or operator. The benefits are not zero-sum — they accrue simultaneously to the vendor, the operator, the regulator, the bank, and the consumer.

When software infrastructure providers are clearly outside the financial services regulatory perimeter, the regulatory system operates more efficiently. Examination scopes are clean. Enforcement actions are precisely targeted. Jurisdictional conflicts are resolved before they arise. Compliance costs per regulated entity decline. The regulatory capacity freed by clear role separation can be directed toward the operators and intermediaries that actually require intensive oversight.

When banking access is calibrated to actual risk — technology supplier vs financial intermediary — legitimate technology companies retain banking relationships and the correspondent banking system operates with greater accuracy. The de-risking problem is not inevitable. It is the product of categorical risk assessment applied to a category that contains entities with fundamentally different risk profiles. Better categorisation produces better outcomes for both banks and technology companies.

When consumers have clear counterparties, consumer protection works as designed. Liability rests where governance rests. The operator who deploys and governs a programme is accountable for its outcomes. There is no diffusion of responsibility across a chain of technical and contractual relationships that consumers cannot observe.

None of these outcomes require any particular regulatory decision or policy change. They are the aggregate consequence of an industry converging on an architectural pattern — clear role separation between software vendor and financial intermediary — that is both legally cleaner and more functionally efficient than the alternatives. The infrastructure already exists. The question is how quickly the surrounding frameworks — regulatory, banking, procurement — update their categorisation models to reflect the distinction.