How multi-rail payments are reshaping compliance architecture, transaction control and the role of the MLRO
Compliance in financial services has traditionally been organised around institutions, customers and accounts. A customer is identified and subjected to due diligence, beneficial ownership is established, sanctions and politically exposed person checks are performed, a risk classification is assigned and subsequent activity is monitored against expected behaviour. Transactions are screened, unusual activity is investigated and suspicious transactions are escalated in accordance with regulatory requirements and internal procedures.
This model remains fundamental, but the infrastructure through which financial activity now takes place is becoming substantially more complex. International payments may involve commercial banks, payment institutions, foreign-exchange providers, local clearing systems, digital-asset service providers and blockchain networks within a single economic transaction.
Stablecoins introduce additional settlement possibilities, while payment orchestration creates the capability to select dynamically between different routes, providers and settlement mechanisms. The consequence is that the compliance function can no longer be understood solely as a control framework surrounding a relatively stable payment process. Increasingly, compliance requirements must form part of the architecture through which the payment itself is executed.
One payment, many financial events
This development is important because what appears to the corporate customer as a single payment may in practice consist of a sequence of separate financial events. A company may initiate a payment in euros from a conventional bank account; those funds may be transferred to a regulated financial institution, converted into a stablecoin, transmitted across a blockchain network, converted into another fiat currency and ultimately credited to a beneficiary through a local banking system. Each stage may involve a different regulated entity, technological infrastructure, jurisdiction and risk environment.
The compliance question therefore extends beyond whether the customer and beneficiary are acceptable counterparties. It also concerns whether the route through which the transaction is executed is consistent with applicable regulation, the institution’s risk appetite, its contractual allocation of responsibilities and the control framework governing the relevant intermediaries.
The transaction lifecycle as the unit of analysis
This shifts the analytical unit of compliance from the individual transaction toward the complete transaction lifecycle. Customer due diligence remains the starting point, but it is no longer sufficient by itself to characterise the risk associated with a payment. The institution may also need to consider the purpose and economic context of the transaction, geographic exposure, counterparties participating in the settlement chain, currencies involved, the characteristics of the selected payment rail, the source and destination of digital assets, and the nature of any wallet or exchange infrastructure involved.
In blockchain-based transactions, additional questions may arise concerning wallet ownership, hosted versus unhosted addresses, transaction history, exposure to higher-risk services and the applicability of Travel Rule requirements. The resulting control environment is therefore broader than conventional payment screening. It combines elements of customer risk, transaction risk, counterparty risk, infrastructure risk and jurisdictional risk.
When routing becomes a compliance decision
For Compliance Officers and Money Laundering Reporting Officers, this has a direct implication for the relationship between transaction monitoring and payment routing. Historically, these functions have often been treated as conceptually distinct. Payment operations determine how a transaction is executed, while compliance determines whether the activity is permissible and whether subsequent behaviour requires investigation. In a multi-rail environment, however, the route itself may alter the compliance characteristics of the transaction.
A transaction that can be executed through several possible providers or networks may present different jurisdictional, counterparty or transparency risks depending on the path selected. A route that is economically attractive because of lower cost or faster settlement may nevertheless be inappropriate because it introduces a restricted jurisdiction, an unapproved counterparty or insufficient information for regulatory purposes. Consequently, routing decisions cannot be optimised solely according to commercial variables such as price, speed and liquidity. Regulatory and risk criteria must form part of the same decision framework.
Orchestration and embedded risk parameters
The emergence of payment orchestration makes this issue particularly significant. Orchestration systems are designed to coordinate multiple payment methods, networks, financial institutions and liquidity sources through a common infrastructure. Their principal operational value lies in the ability to evaluate alternative routes and select an appropriate execution path according to predefined criteria.
From a compliance perspective, this means that risk parameters can potentially be incorporated into the routing logic itself. Jurisdictional restrictions, transaction limits, permitted counterparties, customer classifications and other control parameters can become conditions governing whether a particular route is available.
This does not imply that regulatory judgement can be reduced to an algorithm. Interpretation, investigation and escalation remain inherently judgement-intensive activities. It does, however, imply that routine restrictions and control requirements can be applied systematically at the point at which a transaction is being constructed, rather than being treated primarily as ex post monitoring considerations.
Controls before, during and after execution
Such an architecture has consequences for the design of the control framework. Controls may be required before, during and after execution. Pre-transaction controls may include confirmation of customer status, sanctions screening, beneficiary checks, transaction limits, geographic restrictions and additional approval requirements.
During execution, the system may need to apply counterparty eligibility rules, wallet screening, route restrictions and compliance conditions associated with particular providers or jurisdictions. After settlement, information must remain sufficiently complete to support transaction monitoring, reconciliation, regulatory reporting, investigation and audit.
Traceability across the entire economic event
The relevant design objective is therefore not merely to prevent prohibited transactions. It is to establish traceability across the entire economic event. A Compliance Officer or MLRO should be able to determine who initiated and approved a transaction, which beneficiary ultimately received the funds, which providers participated in the route, where conversions occurred, what controls were applied, which alerts were generated and what information was available when the transaction was released.
This requirement for traceability becomes more demanding as the number of participating entities increases. Multi-provider infrastructure can improve resilience and broaden access to different markets, but it can also fragment the evidential record if customer data, payment instructions, foreign-exchange transactions, wallet activity and final settlement are maintained in separate systems. Investigation then becomes an exercise in reconstructing events across platforms rather than analysing a coherent transaction record. From an AML perspective, this fragmentation is problematic because the effectiveness of transaction monitoring depends not only on the quality of individual controls but also on the completeness and accessibility of contextual information. A technically successful payment architecture can therefore still produce a weak compliance environment if it does not preserve the relationship between customer, instruction, route, settlement and supporting control data.
Allocating regulatory responsibility
An equally important issue is the allocation of regulatory responsibility. The use of orchestration does not remove the legal obligations of banks, payment institutions, electronic money institutions, CASPs or other regulated entities participating in a transaction. Nor should the presence of an orchestration platform create ambiguity about which institution is responsible for particular controls. On the contrary, greater technological interconnection increases the importance of explicit responsibility mapping.
Customer due diligence, sanctions screening, transaction monitoring, blockchain analytics, Travel Rule compliance, alert investigation, suspicious activity reporting and record retention may sit with different entities depending on the structure of the transaction and the regulatory status of the participants. These responsibilities need to be defined contractually, operationally and technically. A well-designed payment architecture should therefore make regulatory responsibilities more visible rather than obscuring them behind a seamless user experience.
Counterparty risk and operational resilience
The same principle applies to third-party and counterparty risk. A payment system that can route transactions across several banks, liquidity providers, exchanges or digital-asset service providers is only as robust as the governance surrounding those relationships. Compliance functions therefore need clearly articulated criteria for approving and monitoring counterparties, including regulatory status, jurisdiction, control environment, sanctions exposure and operational resilience. In an orchestration model, these criteria can potentially be translated into route-level restrictions.
A provider that no longer meets the required standard can be excluded from permissible execution paths, while alternative approved routes remain available. This creates an important connection between compliance and operational resilience. Diversification of payment infrastructure can reduce dependency on a single provider, but alternative routes only contribute to resilience if they have been assessed and approved before they are needed. Contingency arrangements that rely on untested or unapproved counterparties may provide operational optionality while simultaneously introducing unacceptable regulatory risk.
Compliance at the speed of settlement
The movement towards real-time and near-real-time settlement also changes the temporal structure of compliance. Traditional payment systems often contain delays associated with batch processing, settlement windows and correspondent banking. These delays are operationally inefficient, but they can also provide time for manual intervention. Faster payment systems and blockchain-based settlement reduce that interval significantly. Once an irreversible transaction has been released, subsequent investigation may establish the circumstances of the payment but may not be capable of preventing the transfer itself. Preventive controls therefore assume greater importance.
The faster the settlement mechanism, the greater the need for high-quality pre-transaction screening, transaction limits, beneficiary controls, wallet screening and escalation procedures to operate before execution where intervention may be required. This is not an argument against real-time settlement. It is a design requirement: the control environment must be capable of operating at a speed consistent with the infrastructure it governs.
Compliance and efficiency are not opposites
A related consideration is the relationship between compliance and payment efficiency. These objectives are sometimes presented as inherently conflicting. Faster payments are assumed to increase risk, while more comprehensive controls are assumed to increase friction. In practice, a substantial proportion of compliance-related friction arises from fragmented data, duplicated processes, manual exception handling and poorly integrated systems rather than from the substantive regulatory requirement itself.
The more important objective is therefore not simply to increase the number of controls, but to improve their architecture. Where customer information, transaction history, beneficiary data, route information and settlement records are available within a coherent framework, routine checks can be applied more consistently and genuinely exceptional activity can be identified more effectively. Automation in this context is valuable not because it replaces professional judgement, but because it improves the quality and timeliness of the information on which that judgement depends.
Where Atlas fits
This is also the context in which Atlas is intended to operate. Atlas is designed as an orchestration layer connecting different forms of banking, payment, liquidity and digital-asset infrastructure rather than as an independent payment rail. From a compliance perspective, the relevance of such an architecture lies in the possibility of coordinating transaction information, routing logic, regulated counterparties, wallet infrastructure and reporting within a common execution framework.
Regulatory and risk parameters can therefore form part of the transaction process rather than being applied only at its margins. The regulated obligations associated with individual participants nevertheless remain with the entities to which those obligations apply. The objective of orchestration should not be to transfer or dilute regulatory responsibility, but to create an environment in which responsibilities, controls and transaction evidence can be applied more coherently across heterogeneous payment mechanisms.
Payment architecture and compliance architecture converge
The broader implication is that the distinction between payment architecture and compliance architecture is becoming progressively less useful. In a financial system characterised by multiple rails, providers and forms of money, the route through which a transaction moves is itself part of the risk environment. The entities participating in that route, the information available about them, the timing of settlement and the controls applied before and during execution all affect the institution’s compliance position.
As a result, Compliance Officers and MLROs increasingly need to participate not only in the approval of new payment products but also in the design principles governing payment infrastructure. The relevant question is no longer simply whether a particular technology or settlement mechanism is permissible. It is whether the architecture as a whole produces a sufficiently transparent, controllable and evidentially robust transaction lifecycle.
A changing role for Compliance Officers and MLROs
Payment innovation will therefore place greater emphasis on the integration of compliance into infrastructure design. The most effective systems are unlikely to be those that treat AML, sanctions controls and regulatory obligations as external gateways through which transactions must pass. They will be those in which compliance requirements are reflected in customer eligibility, routing rules, counterparty selection, transaction permissions, monitoring and record creation throughout the payment process.
For Compliance Officers and MLROs, this represents a substantive change in role. Their contribution increasingly extends from supervising compliance processes to influencing how financial infrastructure itself is structured. In a multi-rail and increasingly real-time environment, that may be essential to ensuring that innovation in payments produces not only greater efficiency, but also a control framework capable of sustaining that efficiency at scale.
