Flagship module in development

FARO MLRO

AML/CFT compliance intelligence and workflow support for people who need to interpret trusted sources, apply them to real facts, and preserve defensible records.

About FARO MLRO

FARO MLRO is being developed as a modular compliance intelligence model for AML/CFT work. It is intended to help users interpret legal, regulatory, supervisory and user-provided sources in a structured and auditable way.

The module is designed to understand a user's situation, identify the relevant facts, determine which AML/CFT sources and rules may apply, and translate the outcome into clear next steps. It is not a generic chatbot. It is a domain-specific compliance assistant built around trusted sources, structured reasoning and workflow-ready outputs.

Who FARO MLRO is for

FARO MLRO is intended for MLROs, executives, sole practitioners, compliance officers, consultants, regulated organisations, and anyone working in AML/CFT who must understand, evidence, review or communicate AML/CFT decisions.

MLROs and deputy MLROs

For professionals who need to review, justify, escalate and document AML/CFT decisions under pressure.

Compliance officers and analysts

For teams handling onboarding, CDD, EDD, monitoring, internal notes, risk reviews and recurring source lookups.

Executives and directors

For decision-makers who need practical visibility over compliance obligations without losing accountability.

Sole practitioners and smaller firms

For professionals who must comply with AML/CFT expectations without large internal compliance departments.

AML consultants and advisors

For practitioners who need faster issue framing, source checks, client-ready summaries and structured file notes.

Institutional and supervisory users

For organisations that need consistent, neutral and source-grounded support when handling recurring AML/CFT questions.

Why it matters

AML/CFT compliance is not difficult only because the rules are technical. It is difficult because the framework is multi-layered: legislation, regulations, implementing procedures, guidance, supervisory expectations, internal policies, client facts, transaction data and file evidence all interact at the same time.

FARO MLRO is being designed to cut through that multi-source noise. It aims to simplify decision-making without making it casual. The objective is to help users get to the real issue faster, preserve the reasoning behind the conclusion, and produce outputs that can be reviewed, shared, filed and audited.

How FARO MLRO works

FARO MLRO is powered by the proprietary Hybrid Legal Intelligence Model (HLIM). The system is being designed to move through a structured sequence: understand the situation, ask for missing information, determine the applicable sources and rules, apply those rules to the facts, and translate the result into a practical roadmap.

Understand the situation

FARO MLRO begins by turning the user’s question into a structured scenario.

Ask for missing information

Where the facts are incomplete, FARO MLRO should ask targeted questions rather than guessing.

Determine applicable rules

The module is intended to retrieve and apply relevant AML/CFT sources according to source hierarchy.

Apply rules to facts

FARO MLRO maps applicable rules onto the structured scenario and identifies practical outcomes.

Produce an actionable roadmap

The output is designed to be understandable, evidence-linked and useful for implementation.

What FARO MLRO could look like in practice

The example below is illustrative. It shows the intended workflow style: FARO MLRO should not jump straight to a conclusion. It should identify the issue, ask for missing information, treat user documents cautiously, apply the relevant source hierarchy, and turn the outcome into an auditable file note.

Illustrative FARO MLRO workflow

Illustrative workflow only. This is not legal advice and does not represent a live FARO MLRO output. In the live product, conclusions would depend on verified facts, configured rule packs, internal policies, source versions and any required human review.

User

Hi FARO — I need a quick sense-check on a player alert. Customer Albert Epstein opened an account on 25 March. He was online from a Ghana IP when he registered, deposited USD 500, played around 1,000 slot spins, and the balance is now around USD 150. He has just topped up another USD 2,500 and our system flagged it. Is this just the EUR 2,000 CDD threshold issue, or do we need EDD/source-of-funds or MLRO escalation? What should we do before anything is allowed to move?

FARO MLRO

I can help structure the alert, but I should not give a final risk conclusion yet. The threshold point is relevant, but it is not the same thing as suspicion. I need a few facts before the case can be assessed responsibly.

Please confirm or upload:

  • Customer identity document
  • Current proof of residential address
  • Payment-method ownership and issuer country
  • Deposit route / PSP information
  • Sanctions, PEP and adverse-media screening results
  • Source-of-funds or source-of-wealth evidence for the top-up
  • Any internal risk score or alert narrative generated by the operator
  • Whether withdrawal, transfer or further play is currently blocked

Initial control: do not release withdrawals until the required CDD/EDD position has been resolved or escalated.

User

We have obtained the customer's ID document and proof of address. The customer appears to have a Kenya ID. The proof of address is a utility bill showing a Nigerian address. We have not yet confirmed payment-method ownership or screening results.

XXX-id-card.jpg XXX-utility-bill.jpg
FARO MLRO

Thank you. I would treat these as user-supplied customer evidence, not as independently verified documents. The file still needs verification and the jurisdictional pattern needs explanation: Ghana IP at registration, Kenya identity document, Nigerian address evidence, and a new USD 2,500 top-up.

Scenario status after identity/address upload

  • CDD status: incomplete / under review
  • Threshold issue: likely triggered by cumulative deposits, not current balance
  • Document reliability: not verified from image review alone
  • Jurisdictional coherence: unresolved
  • Missing: payment ownership, PSP details, screening results, SOF/SOW evidence
  • Control: withdrawals should remain blocked pending completion or MLRO decision
User

The customer has now provided a payslip as source-of-funds evidence. It appears to be an older payslip from employment in Italy. We still do not have bank statements or PSP evidence linking the salary to the gaming deposits.

YYY-payslip-sof.jpg
FARO MLRO

The payslip may be relevant, but it does not by itself verify the source of the March deposits or the USD 2,500 top-up. I would keep the case under review, maintain the withdrawal restriction, and move to a structured file-note / CRA-style assessment.

Case understood

  • Operator type: Malta B2C remote gaming operator
  • Customer type: individual player
  • Trigger: cumulative deposits likely exceeding the EUR 2,000 remote-gaming CDD threshold
  • Risk features: Ghana IP, Kenya ID, Nigerian address, Italy payslip, missing payment-ownership evidence
  • Document status: user-supplied and not independently verified
  • Decision status: not suitable for automatic clearance
FARO MLRO

I would treat this as a threshold-triggered remote-gaming CDD/CRA case with additional unresolved risk indicators. I would not clear withdrawals at this stage.

Case assessment
1. Recap

The alert concerns an individual player of a Malta remote-gaming operator. The player opened an account on 25 March, registered from a Ghana IP address, deposited USD 500, played approximately 1,000 slot spins, and later topped up a further USD 2,500. The current balance is around USD 150, but the relevant AML/CFT trigger is the customer’s cumulative deposit activity, not the remaining balance.

The documents and facts provided so far do not fully clear the case. The customer appears to have a Kenya ID document, Nigerian address evidence and an older Italy-linked payslip. Payment-method ownership, PSP/deposit-route information, sanctions/PEP/adverse-media screening and a clear link between the payslip and the gaming deposits are still missing.

2. Practical Outcome

Do not release withdrawals or treat the account as cleared until the CDD/CRA position has been completed. On the facts provided, the USD 500 plus USD 2,500 deposit pattern should be tested against the operator’s approved EUR 2,000 remote-gaming threshold methodology, including the applicable conversion approach and aggregation period.

Crossing the threshold does not automatically mean that an STR must be filed. However, this is also not a clean routine-threshold case. The Ghana IP, Kenya ID, Nigerian address, Italy-linked payslip and missing payment-ownership trail create unresolved customer, geographical, interface and source-of-funds questions. The case should remain under CDD/EDD review, withdrawals should remain blocked, and the matter should be escalated to the MLRO or senior compliance reviewer if the inconsistencies are not resolved through reliable evidence.

3. Legal Basis

According to the PMLFTR, S.L. 373.01, Regulation 2, the operator must first determine whether it is acting as a subject person and whether the player is a customer in a business relationship or is carrying out an occasional transaction. Because the user is a Malta remote-gaming operator and the facts concern a player account, the AML/CFT obligations are determined by the PMLFTR, the FIAU Implementing Procedures Part I, and the FIAU Implementing Procedures Part II for the Remote Gaming Sector.

According to PMLFTR Regulation 2 and Regulation 9(1), casino and gaming licensees must apply customer due diligence where the relevant gaming threshold is met. The remote-gaming sectoral procedures then explain how the EUR 2,000 deposit threshold is to be operationalised for player activity. The relevant question is therefore not whether the remaining balance is around USD 150, but whether customer deposits, either singly or cumulatively under the operator’s methodology, have reached or exceeded the EUR 2,000 trigger.

According to PMLFTR Regulation 7, the operator must apply customer due diligence measures. In this case that means identifying and verifying the customer, establishing the customer’s business and risk profile, understanding the purpose and intended nature of the account relationship in the gaming context, applying ongoing monitoring, and keeping the customer information and documents up to date. The customer-supplied ID document, utility bill and payslip should therefore be treated as evidence to be assessed and verified, not as verified facts merely because they were uploaded.

According to PMLFTR Regulation 8 and the FIAU Implementing Procedures, where required CDD cannot be completed, the operator must not simply proceed as normal. The relationship, transaction or withdrawal handling must be restricted or refused as required, and the case must be assessed for possible reporting. In the remote-gaming context, the sectoral procedures specifically support continued account control pending CDD while restricting withdrawals until the required CDD position is completed.

According to PMLFTR Regulation 11 and FIAU Implementing Procedures Part I Chapter 4.9, enhanced due diligence is required where higher-risk circumstances are present. The relevant risk drivers here are not one isolated fact, but the combined pattern: registration from a Ghana IP address, Kenya identity evidence, Nigerian address evidence, an Italy-linked payslip, an unexplained USD 2,500 top-up, and no confirmed payment-method ownership or screening results. Those facts require enhanced review unless they are satisfactorily explained and verified.

According to FIAU Implementing Procedures Part II for the Remote Gaming Sector, the operator should assess customer risk, geographical risk, product/service/transaction risk, interface risk and payment-method risk. The same source also requires attention to document reliability, non-face-to-face onboarding controls, IP/geolocation information, customer source of wealth/source of funds, threshold monitoring, player behaviour and remote-gaming red flags. These are the relevant sector-specific sections for this case, especially the sections dealing with customer identification, customer risk assessment, the EUR 2,000 deposit threshold, withdrawal restrictions pending CDD, inability to complete CDD, and internal escalation or suspicious transaction reporting.

According to PMLFTR Regulation 15 and FIAU Implementing Procedures Part I Chapter 5, if the operator knows, suspects, or has reasonable grounds to suspect money laundering or funding of terrorism, the matter must be reported through the internal reporting channel and, where appropriate, externally to the FIAU. According to PMLFTR Regulation 16 and the corresponding FIAU guidance on tipping off, customer communications must be handled carefully so that the customer is not alerted to any internal report, STR consideration or FIAU-related process.

According to PMLFTR Regulation 13 and FIAU Implementing Procedures Part I Chapter 9, the operator must retain the CDD material, transaction information, internal review rationale, any internal report, any decision not to report, and the evidence supporting the decision. The case note should therefore record both the facts relied on and the facts still missing.

4. Roadmap

First, confirm the threshold calculation. Convert the USD deposits into EUR using the operator’s approved methodology and record whether the USD 500 plus USD 2,500 deposits trigger the EUR 2,000 remote-gaming CDD threshold.

Second, keep withdrawals blocked until the CDD/CRA position is resolved or an authorised compliance reviewer decides otherwise.

Third, verify the identity document and proof of address through reliable and independent means. Do not treat the Kenya ID or Nigerian utility bill as sufficient until authenticity, customer linkage and residential-address reliability have been checked.

Fourth, resolve the jurisdictional pattern. Record why the registration IP is Ghana, why the identity evidence is Kenyan, why the address evidence is Nigerian, and why the source-of-funds document is Italy-linked.

Fifth, obtain payment-method ownership and PSP/deposit-route evidence. The file should show whether the deposits came from a payment instrument or account in the customer’s own name and from which country or provider.

Sixth, complete sanctions, PEP and adverse-media screening and record the outcome.

Seventh, obtain stronger source-of-funds evidence. One older payslip is not enough by itself unless it can be linked to the actual deposits, for example through bank statements or payment records showing salary receipt and onward funding of the gaming account.

Eighth, update the customer risk assessment. Decide whether the remaining facts support standard CDD completion, enhanced due diligence, rejection, account restriction, or MLRO escalation.

Ninth, escalate to the MLRO if the customer does not provide the missing evidence, if the documents cannot be verified, if the jurisdictional explanation remains incoherent, or if the transaction pattern appears inconsistent with the customer’s profile.

Tenth, keep the customer communication neutral. Ask for CDD and payment-verification information without referring to STR consideration, suspicion, FIAU reporting or internal escalation.

RecapFrames the facts, actors, documents and assumptions.
Practical OutcomeStates the operational conclusion and review status.
Legal BasisPreserves the source-linked reasoning basis.
RoadmapTurns the outcome into next steps, controls and escalation points.

Auditability by design

FARO MLRO is being designed around traceability. Every material decision point should be capable of being linked back to the user's facts, the documents considered, the sources retrieved, the assumptions made and the reasoning pathway followed.

The aim is to make compliance reasoning easier to review, evidence, escalate and keep on file.

Stay tuned

FARO MLRO is currently in development. Updates on availability, pilot access and pricing will be released shortly.