October 6, 2026
Author: Joao Lages
AML/KYC task allocation in white-label investing determines whether a branded investment platform has a defensible operating model or merely a collection of vendors. The investor may see one interface, but the service can involve a brand owner, an authorised investment firm, a tied agent, an identity-verification vendor, a payment provider, an issuer and a technology operator. Each can perform part of the workflow. Only some are legally responsible for the anti-money-laundering and counter-terrorist-financing outcome.
The essential principle is simple: technology can execute checks, collect evidence and route cases, but it does not decide which entity is the obliged entity. A regulated firm may outsource tasks while retaining accountability, and a white-label brand may have contractual duties even when it is not the regulated principal. The allocation therefore needs three layers: legal ownership, operational execution and independent oversight.
This guide explains how European teams can assign customer due diligence, risk scoring, sanctions and politically exposed person screening, monitoring, escalation, reporting and recordkeeping. It distinguishes the current EU framework from rules that apply from 10 July 2027 and is general information, not legal advice for a particular platform or jurisdiction.
A white-label journey compresses several organisations into one customer experience. The brand attracts the investor. A platform collects data. A verification provider tests identity documents and liveness. An investment firm may receive or transmit the order. A payment institution moves funds. An issuer accepts the subscription. If the responsibilities are described only as “KYC handled by the provider,” important decisions are left undefined.
KYC is not a single API call. It is part of customer due diligence and a broader AML/CFT control system. That system includes identifying the customer and beneficial owner, understanding the purpose of the relationship, assigning risk, applying enhanced measures where needed, monitoring the relationship, investigating alerts, filing reports with the competent financial intelligence unit and retaining evidence. It also requires governance, staff competence, quality assurance and documented risk appetite.
The practical consequence is that one party can perform a check without owning the regulatory judgment. An identity vendor may report that a passport appears genuine, but the obliged entity decides whether the evidence is sufficient. A screening engine may return a possible sanctions match, but an authorised person must resolve the case. A brand may collect an investor’s answers, but it should not silently alter a regulated firm’s risk rating or approve a relationship outside its mandate.
The first step is to identify the customer-facing regulated service and the entity providing it. For tokenised shares, bonds, fund interests or other financial instruments, the relevant distributor may be an investment firm or another authorised financial institution. For crypto-assets outside the financial-instrument perimeter, a crypto-asset service provider may be the obliged entity. Payment and custody providers can have their own duties for the relationships they maintain. The issuer may also be subject to separate national obligations depending on its status and activity.
Under the current framework, the Fourth Anti-Money Laundering Directive, as amended and implemented through national law, permits an obliged entity to rely on qualifying third parties for specified customer due-diligence measures. Article 25 is explicit that ultimate responsibility remains with the obliged entity relying on the third party. Articles 27 and 28 require access to the necessary customer information and supporting documentation. Article 29 distinguishes third-party reliance from outsourcing or agency arrangements in which the service provider is treated as part of the obliged entity.
The EU Anti-Money Laundering Regulation, or AMLR, will generally apply from 10 July 2027. Its Article 18 creates a more detailed outsourcing framework. An obliged entity must notify its supervisor before outsourced AML tasks begin, remains fully liable for the provider’s acts and omissions, and must understand and control how the task is performed. Certain decisions cannot be outsourced, including approval of the business-wide risk assessment, internal AML policies, the customer risk profile, the decision to enter into a relationship and reports to the financial intelligence unit, subject to limited provisions in the regulation.
The regulated principal is normally the entity that establishes the relevant customer relationship or performs the regulated investment service. It owns the AML policy for that relationship, sets risk appetite, approves the methodology, makes reserved decisions and answers to its supervisor. If a tied agent acts on its behalf, the principal needs sufficient control over the agent’s conduct and records.
The brand owner may design the proposition, acquire users, operate first-line support and collect data through its interface. It should have precise permissions. It may be authorised to explain the process, request missing documents or perform scripted operational steps. It should not make reserved regulatory decisions unless the legal model, delegation, training and supervision expressly allow it.
The platform can orchestrate identity verification, case management, screening, payments, orders and audit logs. Specialist vendors can supply document authentication, biometric comparison, database screening or blockchain analytics. These providers produce evidence and alerts; they do not remove the principal’s duty to validate suitability for its risk model, monitor performance and retain an effective fallback.
The issuer supplies corporate, ownership and product information and may conduct due diligence on subscribers for its own legal purposes. Banks, payment institutions, custodians and registrars may run separate checks for their own relationships. Duplicate checks should be reduced through lawful data sharing and reliance arrangements, but one provider’s approval does not automatically satisfy another provider’s obligations.
Owner: the regulated principal. Contributors: the brand, issuer, platform and specialist risk teams. The principal should document the customer types, countries, distribution channels, instruments, funding methods, expected transaction patterns and exposure to fraud, sanctions and money-laundering typologies. The brand and issuer provide facts, but the principal approves the assessment and any risk appetite derived from it.
Product launch should be blocked until this assessment is connected to controls. If a platform accepts corporate investors, for example, it needs beneficial-ownership logic and authority checks. If it accepts cross-border retail investors, it needs country rules, language support and escalation capacity. If subscriptions can be funded from multiple accounts or crypto-assets, source-of-funds and transfer-monitoring controls must reflect that route.
Owner: the regulated principal. Executor: usually the platform and identity provider. The interface can collect names, dates of birth, addresses, identity documents, corporate records and beneficial-owner information. The identity provider can test document authenticity, compare biometrics and verify data against trusted sources.
The principal should approve accepted documents, verification methods, retry limits, manual-review triggers and country coverage. The EBA’s remote customer onboarding guidelines expect financial institutions to assess the adequacy and reliability of remote tools using a risk-sensitive, technology-neutral approach. Procurement therefore needs more than an accuracy claim: it needs testing evidence, fraud controls, exception handling and ongoing performance monitoring.
Owner: the regulated principal. Executor: the vendor may automate most steps; trained operations staff resolve exceptions. For natural persons, the workflow should connect identity evidence to the person presenting it. For companies, it should identify legal representatives, ownership and control, and the natural persons who ultimately own or control the customer.
Owner: the regulated principal for its customer relationship. Executor: a screening vendor or platform service can generate and prioritise matches. The operating procedure should define list coverage, fuzzy-matching settings, transliteration, rescreening frequency and the evidence needed to close a false positive.
These controls should not be collapsed into one label. Politically exposed person status generally triggers enhanced risk management rather than an automatic prohibition. Targeted financial sanctions can require an immediate block or freeze under applicable law. Adverse information supports a risk assessment but must be evaluated for source quality, relevance and identity match. Escalation routes and decision authority should reflect those differences.
Owner and final decision-maker: the regulated principal. Input providers: the platform, brand, issuer and data vendors. A rules engine may calculate a provisional rating using geography, customer type, product, occupation, source of wealth, expected activity and screening results. Human review is appropriate for complex or high-risk cases and for exceptions outside the model.
The AMLR’s future outsourcing rules are especially clear that the customer risk profile and the decision to establish a relationship cannot be outsourced. Even before 2027, a sound model keeps these approvals with the obliged entity. The white-label interface can present questions and gather evidence, but it should not silently accept a customer because a vendor returned a green status.
Owner: the regulated principal. Executor: the brand or platform can collect declarations and documents; analysts assess plausibility. The level of evidence should be risk-based and proportionate. A routine subscription from an account in the investor’s name may require less evidence than a large transfer from a company, a third-party account or a jurisdiction associated with elevated risk.
The procedure should distinguish the source of the particular funds used for an investment from the broader origin of the customer’s overall wealth. It should also specify permitted payment accounts, third-party payment exceptions and reconciliation controls. Payment data must feed the customer file rather than remain isolated in a separate provider dashboard.
Decision-maker: the regulated principal. Operational support: the platform enforces the result. The case-management system should prevent investment until all required approvals are complete. It should support rejection, temporary restriction, requests for information and conditional approval without exposing sensitive AML reasoning to the applicant.
The brand’s customer-support team needs scripts for delays and document requests, but it should not promise acceptance or disclose that a suspicious-activity review is under way. Escalations need service levels because unresolved cases can otherwise become a commercial pressure point that weakens controls.
Owner: the regulated principal. Executors: transaction-monitoring systems, payment or custody providers and trained analysts. Monitoring should compare actual activity with the expected profile, detect unusual funding or transfer behaviour, and trigger refreshes when identity, ownership, sanctions status or risk factors change.
The platform should send complete and timely events: subscriptions, cancellations, withdrawals, changes of bank account, device and access anomalies, transfers between investors and changes in beneficial ownership. The principal defines detection scenarios, thresholds and review rules. Vendors can tune models, but approval and effectiveness testing remain governed by the principal.
Owner and reporter: the legally designated obliged entity through its authorised AML function. The brand and vendors must escalate facts and preserve evidence. They should not decide independently whether a report is filed unless they are themselves an obliged entity for the relevant relationship.
The workflow needs a confidential path that is separate from general support tickets. Access should be limited, tipping-off risks controlled and filings documented according to national law. Contracts should require rapid cooperation from every party, including retrieval of identity records, payment data, communications and device information.
Owner: the obliged entity for AML records; controller and processor roles must be assessed separately under data-protection law. The system should preserve the evidence, approvals, policy version, screening data, alerts and changes needed to explain a decision. Records should be exportable, readable and available after termination of a vendor contract.
Under GDPR, AML processing still needs a lawful basis, purpose limitation, security and defined controller-processor arrangements. Access to KYC data should follow least-privilege principles. Retention should match applicable AML law and litigation needs rather than an indefinite default. A deletion workflow must recognise records that cannot yet be erased because a legal retention duty applies.
This distinction is frequently missed. In third-party reliance, an obliged entity uses CDD measures performed by another qualifying obliged entity, while obtaining required information and ensuring immediate access to supporting documents. The relying entity keeps ultimate responsibility. The arrangement is not simply a vendor integration and may be limited by the provider’s jurisdiction and regulatory status.
In outsourcing, a service provider performs a task as part of the obliged entity’s process. The obliged entity sets the rules, supervises performance and remains responsible. A document-verification API is commonly part of an outsourced workflow. A referral from another regulated institution may qualify as reliance only when the legal requirements are met and the contract supports the necessary information exchange.
A platform should label each relationship correctly. Calling outsourcing “reliance” does not reduce accountability, while treating reliance as a data shortcut can leave the principal without immediate access to underlying evidence. The legal analysis should be reflected in data flows, contracts and the case-management design.
For each task, the operating manual should name four positions rather than one:
The matrix should cover at least onboarding policy, vendor approval, identity verification, beneficial ownership, PEP and sanctions screening, adverse information, customer risk rating, enhanced due diligence, acceptance, source-of-funds review, monitoring, alert investigation, reporting, periodic review, record retention, data-subject requests, complaints, incidents and partner termination.
Every row should also specify the system of record, required evidence, approval threshold, escalation time and backup owner. A RACI chart without these execution details is informative but not operational. Conversely, an API specification without legal ownership creates a process nobody can defend.
The service agreement should translate the matrix into enforceable duties. It should define scope, service levels, data fields, evidence standards, subcontracting, confidentiality, audit and access rights, incident reporting, regulatory cooperation, business continuity, termination assistance and data return. The principal needs the right to test controls and require remediation.
Financial entities subject to DORA must also address ICT third-party risk. The relevance depends on the entity and service, but AML tooling often supports a critical operational process. Concentration risk, outage recovery, data location, change management and exit planning should therefore be assessed alongside AML accuracy.
Lympid is a viable option for teams that want one coordinated white-label layer instead of separately integrating investment-product workflows, onboarding, payments and tokenisation. Its white-label investment platform can support the branded journey and the operational routing around regulated distribution for eligible products.
The important value is not a claim that one vendor “does compliance.” It is the ability to implement a clear responsibility model across the brand, Lympid, its regulated arrangements and other providers. Product scope, investor countries, legal entities and permissions still determine the exact allocation. Teams assessing the model should also review Lympid’s explanation of how to create an investment platform in Europe without obtaining a standalone licence and its detailed investor KYC/AML onboarding flow.
Effective AML/KYC task allocation in white-label investing separates accountability from execution. The regulated principal owns the AML framework, risk appetite and reserved decisions. The white-label brand operates within a defined mandate. Platforms and specialist vendors collect evidence, automate controls and route cases. Issuers, payment providers and custodians contribute information and meet their own obligations.
The model should work at three levels: the legal documents state who is responsible, the systems enforce the allocation, and the records prove what happened. Building that alignment now also prepares the platform for the AMLR outsourcing rules that apply from 10 July 2027.
If you are considering launching a tokenised investment product, speak with Lympid.
Book a call with us today and get a free assessment.
