In June 2024, the Financial Conduct Authority (FCA) published feedback on good and poor quality applications under the existing cryptoasset anti-money laundering (AML) and counter-terrorist financing (CTF) regime (Feedback). This four-part blog series will aim to provide crypto firms and their compliance personnel (including Money Laundering Reporting Officers (MLROs) and Nominated Officers (NOs)) with some additional guidance and clarification on the Feedback that may assist firms.

It will cover relevant issues concerning money laundering (ML), terrorist financing (TF), proliferation financing (PF), and The Money Laundering, Terrorist Financing and Transfer of Funds (Information on the Payer) Regulations 2017 (MLRs). PART II will address sub-areas 4-7 previously identified, namely:

     4. policies, systems, and controls (PSCs);
     5. transaction monitoring (TM) and blockchain analysis (BA) coverage;
     6. group structure and reliance on group policies and procedures (GPPs); and
     7. outsourcing.

SUB-AREA 4: PSCs

The FCA states that crypto firm applicants should:

1. have PSCs in place to appropriately manage and mitigate risks identified in the Business-Wide Risk Assessment (BWRA);
2. adequately evidence the firm’s assessment of the strength of these controls;
3. be prepared to explain the rationale behind why firms consider certain standard controls do not apply;
4. have PSCs that demonstrate how a firm’s AML framework operates daily; and
5. provide a clear methodology applicable to Customer Risk Scoring (CRS).

A firm’s PSCs represent a complex area that requires a comprehensive and systemic approach to be adopted. This could start from a high-level perspective (systems) and then transition to more detailed analysis at a granular level (controls), so firms should aim to identify:

1. all the different systems in place within a firm (e.g., AML/CTF, business continuity, compliance, custodian, governance, liquidity, outsourcing, payments, risk management, trading systems);
2. individual components within such systems;
3. all controls within such systems and components; and
4. how such systems, components, and controls are monitored and tested.

This should ideally include technical diagrams which identify the systems in place, as well as their components and controls. So, for instance, the FCA states that the AML framework (system) should include components such as:

1. BWRA;
2. Customer Risk Assessment (CRA);
3. Due Diligence (DD);
4. Screening;
5. Suspicious Activity Reporting (SAR);
6. Training; and
7. TM.

Each of these components would then have controls in place that would need to be identified. For example, customer DD (CDD) would have controls that govern whether enhanced, regular, or simplified DD is to be applied. Then, if enhanced DD (EDD) is to be applied, firms must then identify what the EDD triggers to be used by the firm are. A few examples of crypto EDD triggers include:

• high-risk customer profiles (based on CRS/CRA);
• large value transactions;
• servicing of pseudoanonymous cryptocurrency accounts;
• the customer is involved in cryptoasset mining operations in a high-risk jurisdiction (e.g., Iran);
• the transaction is connected with a high-risk jurisdiction; and
• the transaction relates to higher risk cryptoassets (e.g., privacy tokens).

What makes PSCs more difficult in crypto firms, is that they cover new and more complex areas that may not normally be addressed in traditional finance (TradFi) PSCs. For example, controls governing:

1. a firm’s reliance on external crypto ecosystems for liquidity;
2. different or novel business-to-business (B2B) models;
3. market maker risk mitigation;
4. native token trading;
5. reliance on peer-to-peer (P2P) platforms;
6. sub-custodian crypto services;
7. the interoperability of a firm’s products; and
8. white labelling services.

Addressing PSCs is a process that is typically very documentation heavy. Systems, components, and controls must be identified, documented, and diagrammed. It is only then that policies are developed to reflect finalised operations. The problem for crypto firms is that this process becomes even more burdensome because of the complexity of crypto operations.

In reality, crypto firms will likely be required to carry out even more preparations and work than normal to adequately address PSCs. However, what seems to have been occurring is the opposite, they seem to have been carrying out even less than what would normally be required for TradFi firms. It is clear that the FCA will not tolerate such laxity in submissions and emphatically states:

“We will not approve an application where the applicant has an underdeveloped AML framework or a weak governance structure” (FCA, 4 June 2024).

Theoretical examples provided by the FCA include, applicants not carrying out a holistic assessment of risk presented by a customer in CRS, or applicants not taking into account the risk-based approach (RBA) (Financial Action Task Force, October 2014). This laxity also seems to have manifested in drafted policies. A stark example provided by the FCA is where an applicant’s business model dealt only with institutional customers, but its documentation referred to “Retail Customers” instead.

This does not represent a simple typographical error, but rather a huge operational mistake in terms of PSCs and FCA regulatory requirements. The FCA therefore warns firms NOT to submit documents and policies that are clearly generic/off-the-shelf, and that have not been tailored to a firm’s business model or cryptoasset activities. 

SUB-AREA 5: TM AND BA COVERAGE

The term ‘blockchain analytics’ is used to describe the use of specialised tools and techniques to identify, collect, analyse, cluster, and interpret blockchain and crypto data. This data is typically visually represented. Data may be obtained from a broad range of publicly accessible sources, such as blockchains, crypto wallets, protocol data, and transactional data.

Blockchain analytics tools can refer to certain types of tools such as ‘block explorers’ (used to analyse blockchains and transactions), or to proprietary tool providers, such as Chainalysis, CipherTrace, Coinpath, CryptoQuant, Dune Analytics, Elementus, Elliptic, Messari, and TRM. Examples of blockchain analytics techniques include address clustering, heuristic algorithms, network analysis, temporal analysis, token analysis, transaction graph analysis, and TM.

Blockchain analytics tools and techniques cover a huge range of areas and use cases, such as detecting anomalies, identifying connections, identifying trends, monitoring participant activity, providing audit trails, revealing relationships, segmenting transactions, tracking fund destinations and sources, and verifying transactions.

In practice, the term ‘blockchain analysis’ (BA) may therefore be used to generally refer to all the different blockchain analytics tools, techniques, metrics, and strategies that may be employed by crypto firms and individuals. However, when BA is used for AML/CTF purposes, blockchain transactions may be specifically analysed to:

• aggregate transactional data with similar assigned typologies;
• facilitate economic activity, link, and risk analysis;
• identify flow of funds;
• identify high risk or illegal sources (e.g., darknet, unregulated exchanges);
• identify interconnections between crypto wallets and real-world identities;
• identify interrelationships between crypto transfers;
• identify smaller transactions that are grouped together to avoid thresholds;
• identify potentially illegal transactions or illicit fund sources;
• identity suspicious transactions, wallet addresses, and patterns;
• identify the use of privacy-enhancing tools (e.g., atomic swaps, internet protocol (IP) anonymisers, mixers, stealth addresses, tumblers); and
• identify the use of specified P2P crypto exchanges.

In business operations, TM can be used by crypto firms to identify suspicious actors, activities, crypto exchanges, patterns, transactions, trends, and wallets. By combining BA with TM, crypto firms can create highly advanced and sophisticated systems to identify, address, and report ML/TF/PF risks. Not only can these types of systems be applied across huge volumes of customer and transactional data, but they can also provide real-time and predictive analytics.

Nevertheless, TM and BA coverage will almost certainly prove to be one of the most challenging areas for many crypto firm applicants. There are a number of reasons why this may be the case, such as:

• crypto transactions may involve the use of pseudonymous identities, pseudonymous transactions, and cryptocurrency mixing services or tumblers (e.g., Mixero, Tumbler.io);
• crypto transactions may involve the use of privacy cryptocurrencies (e.g., Dash (DASH), Monero (XMR));
• there is no standardised, universal approach to TM and BA coverage; and
• TM and BA coverage is complex and challenging, and this becomes even more so as firms grow in size and complexity of operations.

For crypto firm applications, the FCA states that crypto firms:

1. must demonstrate that the firm has effective TM and BA coverage which is adequate for the firm’s size and complexity, and which includes both fiat and cryptoasset transactions;
2. must have compliance resources that are sufficient to monitor transactions and execute alert escalation and treatment;
3. should demonstrate adequate coverage of various types of currencies and transactions, via its BA and fiat based tools;
4. should ensure that TM tools are tailored to the firm’s business offering and customer population; and
5. should ensure that TM tools are reviewed on a regular basis to make sure that rules, scenarios, and thresholds remain appropriate.

Given these requirements, we can immediately see that there is no ‘one-size-fits-all approach’ that can be employed by crypto firms to implement TA and BA frameworks that are compliant with FCA requirements. In addition, there is virtually no guidance on this area provided by the FCA. As a result, crypto firms are effectively left to assess and evaluate TM and BA coverage subjectively (based on an internal assessment), instead of objectively (based on clear objective standards provided by the FCA).

So, in effect, the FCA expects crypto firms to get TM and BA coverage right, but at the same time provides virtually no rules or guidance as to exactly what it is that they should be getting right in the first place. The proportionality requirement specified by the FCA is even more problematic for crypto firms (i.e., TM and BA coverage adequate for the firm’s size and complexity). This is because size and complexity will affect crypto firms in different ways depending on the underlying business model.

An institutional crypto custodian such as ‘Komainu’ may deal with huge volumes of cryptoassets (size), but it may not require the most advanced and sophisticated TA and BA coverage because of the long term, lower risk nature of the services provided (i.e., collateral management, custody). Two crypto firms of similar size may feature huge differences in terms of complexity of operations. One firm may offer a simple crypto on-ramp (fiat-to-crypto gateway), whilst the other firm may offer multiple transaction types and wallets.

Even then, the range of cryptoassets dealt with can again lead to huge differences. For instance, ‘MoonPay’ enables individuals to buy, sell, and swap multiple cryptoassets across multiple crypto wallets, including digital collectibles and non-fungible tokens (NFTs). This may require highly advanced and sophisticated TM and BA coverage because of the highly unique AML/CTF risks presented by digital collectibles and NFTs. Consequently, crypto firms may likely find it difficult to accurately assess the adequacy and effectiveness of TM and BA coverage, and to accurately assess the level of compliance resources that are required.

Moreover, the experience, knowledge, and skills of blockchain analytics tools and techniques that may actually be needed by crypto firm MLROs/NOs may be extremely advanced in nature. Knowing how to use one or two blockchain explorers is not enough. If we throw limited finances into the mix, it is easy to see why crypto firms may be tempted to subscribe to blockchain analytics tools to appear compliant, when in fact they do not have the expert personnel and/or operational expertise needed to actually operate them. This is an area which will likely be closely monitored by the FCA in future applications, as it states:

“The applicant should not have compliance staff that lack the skills to carry out blockchain investigations despite having blockchain analytics tools” (FCA, 4 June 2024).

SUB-AREA 6: GROUP STRUCTURE AND RELIANCE ON GPPs

The FCA states that crypto firm applications:

1. must focus on the firm’s business model and explain how proposed cryptoasset activities relate to the MLRs;
2. must demonstrate how the MLRs will be complied with by beneficial owners, managers, officers, and the firm;
3. should provide a clear and complete description of the organisation and proposed management structure; and
4. should include a clear description of the firm’s group structure, ongoing activities, regulatory status, and relevant jurisdictions (where applicable).

The application will likely be more complex and problematic where a crypto firm operates within a group structure, especially one that operates both within and outside the United Kingdom (UK). The information provided by a crypto firm should be detailed. For instance, the organisational and management description should cover:

• details of key individuals within the firm;
• a description of responsibilities;
• curricula vitae (CVs); and 
• relevant expertise and qualifications.

The main takeaway in this area is that crypto firms must put in the work to cover this area in detail. This is why the FCA has expressly stated that it will NOT approve an application where the firm has simply submitted GPPs. This reflects a lazy approach which assumes that GPPs are somehow self-explanatory – they are not. GPPs must be explained and contextualised to real world operations.

This includes individual contextualisation not just generic contextualisation when operating across multiple jurisdictions (i.e., if a firm operates across multiple jurisdictions it must explain and contextualise to each specific jurisdiction). This is likely what crypto firms have either found to be difficult, or have failed to do in sufficient detail. Firms must ensure that they explain how GPPs apply to the firm, and they must also demonstrate how GPPs ensure the firm’s compliance with the MLRs.

This means identifying how GPPs are applied and operationalised within the firm, and showing which departments and individuals are responsible for the firm’s legal compliance with the MLRs. In order to demonstrate how the MLRs will be complied with by beneficial owners, managers, and officers, crypto firms must describe in detail what rules, policies, and procedures apply to such individuals, and what steps will be taken by each type of individual within the firm.

SUB-AREA 7: OUTSOURCING

The FCA states that crypto firm applicants:

1. must provide complete information regarding outsourcing arrangements (i.e., outside/within a group, outside/within the UK);
2. must put in place robust oversight to ensure outsourcing providers comply with legal obligations set out in the MLRs;
3. must provide policies around outsourcing and service level agreements (SLAs);
4. must demonstrate sufficient oversight of the outsourced activities; and
5. must provide evidence that demonstrates that appropriate assurance testing of the outsourced activities will take place.

The keys issues for crypto firms to understand and address are:

• ISSUE 1: regulatory obligations (i.e., legal responsibility and liability) will always remain with the crypto firm;
• ISSUE 2: outsourcing requires systems and controls (S&C) to provide effective governance and oversight of outsourcing arrangements (including appropriate assurance testing);
• ISSUE 3: outsourcing arrangements need to be considered at all levels of the firm.

These issues can be illustrated through example regulatory requirements and a case study.

Different regulatory requirements governing outsourcing arrangements are set out in the Senior Management Arrangements, Systems and Controls (SYSC) part of the FCA Handbook (e.g., SYSC 3 Systems and controls, SYSC 8 Outsourcing). SYSC 3.2.4G (01/12/2001) states that a firm cannot contract out of its regulatory obligations. Firms sometimes believe that because they have outsourced services, they pass on regulatory responsibility for such services. This is a mistaken view. A legal outsourcing agreement or SLA cannot pass on FCA regulatory responsibility to a third-party provider (ISSUE 1).  

In 2019, the dual authorised firm ‘R. Raphael & Sons plc’ (Raphaels) was fined £1.89 million for failing to manage its outsourcing arrangements properly (FCA, May 2019; FCA, Raphaels; PRA, Raphaels). Raphaels’ S&C which provided oversight and governance of its outsourcing arrangements were found to be inadequate. Firms sometimes believe that because they have outsourced services, they are no longer responsible for monitoring and supervising such outsourced services. This is a mistaken view. In Raphaels, the firm had failed to implement effective governance and oversight of business continuity and disaster recovery outsourcing arrangements (ISSUE 2).

In Raphaels, outsourcing arrangements had also not been effectively considered at all levels of the firm. It was found that the firm had failed to adequately consider outsourcing at the board level and within departmental risk appetites, there were no processes in place to identify critical outsourced services, and there were also flaws identified in the firm’s initial and ongoing DD of outsourced service providers (FCA, May 2019; FCA, Raphaels; PRA, Raphaels) (ISSUE 3).

TO BE CONTINUED