Software is always a moving target. Software cannot be tangible at all times but is subject to constant further development and enhancement. Even Microsoft announces a new Windows release after having promised to have a final version 10 with incremental upgrades. In the AML compliance sector, i.e., AML, KYC and transaction screening, after a successful go live the next upgrade or migration project is already in progress since new regulations and security features demand enhanced versions. When selecting a new compliance system, there are many questions to be asked - one of which is the "cloud question", on which we will briefly provide some important aspects for your decision-making process. There are many promises such as lower costs, faster deployments, scalability, flexibility, future proofing and so on - which you can find in different flavors on all cloud software provider's websites.

Depending on the jurisdiction, several restrictions and laws in the context of storing sensitive data in the cloud must be adhered to. We will not even scrape the surface about their details, since this is a separate topic but still name two important regulations: GDPR and all its aspects can easily fill a week full of workshops, whereas MaRisk (see BaFin AT9) makes it more difficult to be compliant. One important aspect is the location of the cloud servers. It might be necessary, or at least favorable, to have the data not leave the country. Commercial cloud platforms like AWS, Google, Azure offer their services in multi-national regions, which could be a deal breaker for businesses in smaller countries. If you have found a suitable region, which is outside of the main areas (such as US or UK), it is possible that not all cloud services are currently on offer.

The next important factor is experience: do you already use cloud software in your company (other than Office365) and is the respective compliance software, e.g. screening, monitoring or research system, cloud ready or preferable cloud native? Because of its overall importance, the compliance department should not be in a position to pilot new technologies, it should rather follow the strategy than lead it. The trickier question is the latter, is the software cloud native? Since most solutions will be closed-source software, here are some indicators on how to determine this:

  • Built-in scalability and high availability
  • Convincing number of actual installations
  • Fully automated deployment pipeline
  • Divided into microservices rather than monolithic blocks
  • Open-source usage with adequate versions (OpenJDK 12 vs. Oracle Java 8, or PostgreSQL vs. Oracle Database)

In the past, open-source software was often considered a no-go in the banking and compliance sector due to security and support issues. There are controversial discussions whether closed or open-source software is considered to be more secure. Most Linux distributions offer commercial support. Database systems (Mongo, PostgreSQL, Couchbase) also are backed by companies, the business model of which is to provide professional support and which thus can be forced by their customers to patch their systems to protect against any upcoming security vulnerabilities and to close any potential security gaps. In some sense this trend can be seen as the “best of both worlds”, the code is still freely available, but you can still expect enterprise level support.

Having legacy software that run in a cloud environment is possible, but in some sense this combines the worst of both worlds. The setup process can be complex. Dependencies to database and (Windows) operating systems may be in place. The hardware costs could be much higher since virtual machines are used instead of lightweight containers. Cloud environments claim to reduce costs. However, a virtual server with real CPUs and exclusively reserved memory costs much more if you host them yourself or if a third party also wants to have its share. For a quick comparison, just go to some web hosting companies and compare the server costs of e.g. AWS EC2 or Microsoft Azure VM, which do not even include storage. Therefore, one should carefully distinguish between running virtual machines on the "internet" and cloud-native solutions.  The former will never save costs, the latter has the potential to save costs. It is very important to have a concept of the running costs of the solution, which will be paid directly or indirectly by the bank.

Another important aspect is the solution's performance. Does the provider guarantee response times and operating time (and are they covered by the cloud provider in the background)? If you buy Software-as-a-Service, all these aspects are ideally part of the contract and within the area of responsibility of the software provider.

Especially when the backend of the environment is not accessible to the end user or the tech team of the bank, it is important to have good APIs for extracting reports, logs and audit trails. The bank's compliance team is still responsible for compliance, so the available reports should be well established and tested. Nobody ever wants to hear this imaginary conversation:

Q: Dear vendor, can you please provide a report about all alerted transactions of the last 13 months and the respective users working on these alerts?

A: Dear customer, we kindly refer to the standard API package you have ordered, which does not cover any transaction details.

If the solution were to be on-premise, technically skilled consultants could be called and they may be able to produce some ad-hoc extracts from the database to please the auditor. Such a backend access is hardly possible with a real cloud solution - especially not with the assumed time restrictions in the imaginary situation.

While trending towards a cloud implementation, you should consider a potential vendor lock-in. Is it possible and feasible to switch from AWS to Google Cloud, for instance? All major cloud offerings come with hundreds of special services on which the application architecture may be built on. Using those services for developing a cloud solution might be smart and state of the art, but when the cloud provider is turning “evil” or just pricey, it could be difficult or almost impossible to switch providers. There are also software providers for application middleware to have the flexibility of AWS/Google/Azure without the lock-in effect such as dapr.io and similar frameworks.

Hybrid Cloud may be a valid third option, especially for stateless requests such as real time name and transaction screening. In this scenario, the user frontend is hosted on-premises and the CPU/IO heavy lifting is done in the cloud. It also could be a good idea to use the cloud for temporary projects such as parallel run and system migrations due to the almost unlimited flexibility of the hardware.

The answer to the cloud question is most likely "it depends". Newly established businesses are trending to go cloud native from the start. Larger institutes are happy to build their own cloud environments, since cloud does not necessarily mean to buy in one of the large providers but is rather a deployment and software design pattern. In the process of finding a suitable answer, my colleagues and myself from msg Rethink Compliance are well equipped in this domain and have profound experience in cloud, hybrid cloud and on-premise deployments to best assist you in this landmark decision.



Malta – the centre of criticism for years. As the first EU member state, the country has recently made it to the grey list of the Financial Action Task Force (FATF) due to increased and persistent money laundering and terrorist financing risks. The "grey list" is a global list of countries under increased scrutiny for deficiencies in the implementation of FATF standards.

Being an international supervisory authority, the FATF sets the standards and recommendations for combating money laundering, terrorist financing, and financing of weapons of mass destruction (proliferation) and controls their implementation on a regular basis. More than 200 states and jurisdictions are committed to complying with FATF standards, including all EU member states.

For many years, the state of Malta has repeatedly appeared in connection with corruption, money laundering, and organised crime. Nevertheless, the EU Commission has been inactive to date and even defended Malta at the FATF General Assembly - despite the fact that, among other things, the island state's "Blockchain Island" strategy is viewed with concern within the EU. Crypto companies gain access to the EU via Malta. For instance, Crypto.com received a Virtual Asset License on July 08, 2021, allowing it to do business within the entire EU.

Malta is not alone. Other European countries also have shortcomings in implementing and enforcing anti-money laundering laws and regulations. By November 2020, the FATF reviewed a total of 18 EU member states, and not a single one of them achieved a high level of effectiveness in terms of key indicators for combating money laundering.

Interesting in this context are countries, such as Latvia and Andorra, where glaring deficiencies in their processes have led to bank closures. Latvia also played a role in the "Russian Laundromat" affair. However, the FATF has not included either country in the grey country list to date. Perhaps this is due to the fact that Latvia and Andorra are members of MONEYVAL[1].

Cyprus provided another example of questionable action with the "Golden Passport" programme launched in 2013, which - according to the official announcement – was supposed to "attract foreign capital and support its own real estate market due to the financial crisis." The highlight: Cyprus has promised NON-EU citizens Cypriot citizenship if they invest at least two to two and a half million euros either in real estate or in a company with at least five employees or in shares of Cypriot companies and Cypriot government bonds. In this way, the Cypriot state received more than eight billion euros within six years, partly in capital and partly in investments. For the investors, this was a lucrative business, because in addition to Cypriot citizenship and the associated right to enter the EU, the Cypriot EU passport gave its holder the right to enter more than 150 countries around the world without any visa. In 2020, Cyprus discontinued the programme after pressure from many other EU member states. Bulgaria and Malta had similar programmes in place.

What are the Consequences of Malta's FATF Assessment for Obliged Entities according to the Anti-Money Laundering Act (AMLA)?

According to the European Commission Delegated Regulation (Directive (EU) 2015/849), enhanced due diligence requirements are to be applied for third countries.

Extract from Directive (EU) 2015/849:

Having regard to Directive (EU) 2015/849 of the European Parliament and of the Council (...) on the prevention of the use of the financial system for the purposes of money laundering or terrorist financing, (...), and in particular Article 9(2) thereof, whereas:

(2) All Union obliged entities under Directive (EU) 2015/849 should apply enhanced due diligence measures in their relationship to natural persons or legal entities established in high-risk third countries, thereby ensuring equivalent requirements for market participants across the Union.

Malta, as a member of the EU, does not fall under the definition of a third country. From this, obliged entities under the AMLA can deduce that the application of enhanced due diligence requirements in the case of

- business relationships with the Maltese state,
- business relations with natural and legal persons domiciled in Malta, or
- business relations with natural and legal persons from Malta

is not indicated. However, the inclusion of Malta in the "grey list" should lead to a corresponding adjustment in the risk analysis and, if necessary, to measures being taken (see also FATF: http://www.fatf-gafi.org/publications/high-risk-and-other-monitored-jurisdictions/documents/increased-monitoring-june-2021.html). In addition, an adjustment or extension of the research system used can also be derived in order to, among other things, examine and monitor payment transactions with Malta more closely.

This is not the first time that Malta has shown itself to many obliged entities as a country with money laundering-relevant risks. Already in 2017, Malta came into the focus of institutions obliged to the AMLA in Germany. With the amendment of the German AMLA and the extension of §2, all organisers and brokers of games of chance were also obliged to comply. The problem: most providers of (online) gambling platforms were based in Malta, which undermined German regulation. 

In this context, a digression on the state treaty for the new regulation of gambling in Germany is of interest. It came into force on July 01, 2021. Concluded between all 16 federal states in Germany, the new State Treaty on Gambling 2021 (GlüStV 2021) regulates the framework conditions for the organisation of games of chance nationwide. In order to be allowed to operate gambling (online or on site as a gambling hall), the operator needs an official gambling license. With the new gambling treaty, gambling and operating in this field are now legalized. 

Before that, gambling in Germany was more of a legal grey area, actually illegal, but still somehow legal. According to German law, operating and gambling in gambling halls was generally prohibited; only gambling in state lotteries was allowed. In 2011, the state of Schleswig-Holstein passed a special regulation, but none of the other states agreed to it. As a result, gambling in Germany experienced only partial legalisation. Despite severely restricted licensing, new online casinos were founded all the time. European law made it possible: gambling is legal if the provider has a corresponding license within the EU. Therefore, most gambling operators are based in Malta or Gibraltar, and gambling in Germany had to be tolerated. 

Due to the inclusion of Malta on the so-called "grey list" of the FATF, the obliged entities are now required to take appropriate measures. It will be interesting to see if and when the European Commission will put Malta on the EU list of countries (DelReg) and whether Malta will remain the only country in the EU on the FATF's so-called "grey list".


[1] MONEYVAL was established in 1997 and is a Committee of Experts of the Council of Europe whose mission is to monitor and facilitate the implementation of standards against money laundering and terrorist financing. MONEYVAL includes countries that are members of the Council of Europe but not members of the FATF. In its investigations, MONEYVAL refers to the standards published by the FATF and reports its findings to the FATF. 



On June 8, 2021, the German Federal Financial Supervisory Authority (BaFin) concretised the legal obligations for obliged entities pursuant to Section 2 (1) No. 1 of the German Anti-Money Laundering Act (GwG) with the publication of the Interpretation and Application Guidelines (AuA) for credit institutions. As already outlined in the blog post by my colleague Uwe Weber, item 1 of the AuA BT (special section) imposed on credit institutions that the origin of funds in cash transactions must be clarified and the associated verification and documentation obligations must be applied by August 8, 2021.

My blog post deals with item 6 of the AuA BT. Here, BaFin specifies the appropriateness of the data processing systems (DP systems) used:

Selection, Nature, Suitability:

The credit institution must ensure that the data processing system used

1. can be flexibly parameterised in order to be adapted to the business activities of the credit institution and can be updated at any time if new or changed findings from the institution-specific risk analysis are available.

2. principally enables the credit institution to identify transaction patterns, anomalies, and deviations.

3. contains an indication model that enables individual configuration, taking into account the relevant typologies in the area of money laundering, counterterrorism, and other criminal acts as well as the current publications of the FIU.

4. maps not only customer and product risks but also country risks and risks of terrorist financing.

5. allows indications to be parameterised with regard to the prevention of money laundering, the financing of terrorism, and - where necessary - the prevention of other criminal acts.

6. adequately covers the increased risks as defined in Section 15 (3) GwG.

7. allows names to be checked for similarities using fuzzy logic as part of the sanctions screening process.

8. supports the use and regular updating of lists that reflect the legal requirements (sanctions lists, embargo lists, PEP lists, etc.).

9. contains or is supported by evaluation and statistical functions to perform ad-hoc research and to access evaluations for regular updating and further development of the risk analysis.

10. is capable of receiving and processing all relevant data from the relevant IT systems, i.e., primarily from the payment and transaction systems and the customer master databases of the credit institution. The topicality of the data must be guaranteed at all times.

11. is capable of mapping certain case constellations which, due to their design, do not pose any risks under money laundering law and can therefore be excluded.

12. is able to display the generated hits in full (cf. Section 6 (1) Sentence 2 GwG).

13. particularly in the case of IT-based decisions, shows the main influencing factors for each hit generated and plausibly presents the occurrence of the hit result (prohibition of "black boxes").

14. can mark missing data and work with "default" values until they are corrected. In concrete terms, this means that if risk-relevant data is missing, a risk-increasing default value must always be assumed.

15. can also include historical data.

It is permissible to use different systems for different tasks (e.g. monitoring, screening). The decisive factor is that the systems used cover the above-mentioned aspects in their entirety.

All in all, these are not new or previously disregarded factors, but BaFin has hereby concretised the previously vague definitions and created more clarity. Overall, it becomes clear that when a new system is introduced, the market must be analyzed intensively to ensure that all aspects of appropriateness are sufficiently taken into account when selecting the system. The area of money laundering prevention plays a special role in this context because, in addition to the purely technical components, the specialized components in particular are decisive for the selection of a suitable system.

In addition to the quality and efficiency of the DP systems used, the quality of the data and information also plays a decisive role in the evaluation of the overall system. The higher the quality of the data in the source systems, the higher the quality of the outputs from a DP system, the so-called information quality, and thus the functionality of the system.

Data Quality:

To measure data quality, the following criteria are typically used:

- correctness,
- completeness,
- reliability,
- accuracy,
- uniformity,
- uniqueness,
- relevance,
- consistency and
- topicality.


The functionality of a DP system is given if

  1. the accuracy and topicality of the indications, rules, thresholds, scores, and risk classification systems are checked regularly and on an ad-hoc basis, with particular regard to all relevant legal changes, regulatory requirements, warnings, and information.
  2. significant changes in the institution's risk analysis are taken into account in the calibration of the system.
  3. regular professional maintenance, overhaul, and - if necessary - technical upgrading of the hardware of the DP system are carried out to guarantee its functionality.
  4. the smooth cooperation of the individual components and their interfaces to the DP systems is ensured at all times ("end-to-end"). The credit institution shall continuously verify the proper functionality of the DP systems and regularly ensure a quality control of the DP systems by an independent auditor.
  5. the credit institution takes into account the event of a malfunction or failure of the DP system in the contingency plan pursuant to AT 7.3 of MaRisk (Minimum Requirements for Risk Management.
  6. changes to the legal requirements regarding the use of DP systems and their subject of regulation are implemented without delay after they come into force.

These requirements are not entirely new, but they do specify the need for the business and technical areas to work closely together in order to guarantee functionality. It becomes clear that, in addition to the credit institutions, the providers of such IT solutions also have a responsibility to ensure that their systems are regularly updated in order to reflect changing or new requirements.

Just as the quality of data and information mentioned above contributes to the effective and efficient use of DP systems, a proper mapping of the data supplied from the source systems to the database fields of the DP system is part of the basis for full functionality. When selecting the DP system, it must be guaranteed that the DP system is designed to include the required data in the database in a sustainable (re-generable) manner. The requirements for the mapping of a DP system in the area of money laundering and terrorist financing prevention are very high as it is not sufficient to simply store the data. Instead, the data must be recognizable and reproducible within the legal deadlines, even if the content of the data field changes, but it must not be possible to manipulate it. Ideally, the DP system is capable of naming the data fields according to the designations from the source systems.


The DP system must allow all adjustments to the parameters (settings, indications, authorizations) as well as all hits generated together with hit documentation and, if applicable, suspicious activity reports pursuant to Section 8 GwG to be documented and archived in such a way that a knowledgeable third party can reconstruct these processes within a reasonable period of time.

It must be taken into account that

  1. generated hits must be documented in such a way that the hit analysis and the resulting findings are recognizable and comprehensible.
  2. responsibilities are identifiable at all times.
  3. sufficient justification is provided which conclusively demonstrates the regularity and legality of the change.

The documentation requirements are therefore now specified for the first time and also clearly described in terms of scope. Whereas previously these were merely general documentation requirements, they are clearer definitions now. However, there is still a margin of discretion. Particularly in connection with documentation requirements, the auditing bodies, associations, and organisations as well as auditors at banks and saving banks will probably take a closer look in the future.

A key requirement of item 6 is that the DP systems must be able to map the relevant typologies in the area of money laundering, counterterrorism, and other criminal acts as well as the indications arising from current publications of the FIU. In addition to the requirements already described for the data supplied and their usability in the DP system, this also results in requirements for documentation and auditing: all relevant facts relating to the parameterisation of the DP systems (such as rules, indications, etc.) must be taken into account in the documentation.

With regard to typologies and indications, there are a large number of documents that make it difficult to record all typologies. This is because the FATF alone has published more than 50 publications related to money laundering, terrorist financing, and proliferation in 2019 and 2020. If you add the area of other criminal acts, more than 300 typologies come together. Here, msg Rethink Compliance recommends keeping a corresponding register, including regular updates.


When assigning user rights for the DP system, it must be guaranteed that the user concerned has all the necessary professional qualifications and expertise. This applies both to the company's own employees and to external consultants.

When assigning rights, it must be ensured that it is clear which function the respective user is to perform and that only the rights relevant to this function are assigned to him. This results in the requirement that employees entrusted with the use of the DP system receive sufficient training and professional development in order to ensure transparent operation in compliance with MaRisk.

The anti-money laundering officer is responsible for this. He is responsible for the technical further development of the DP system, the modification of existing indications, rules or scenarios, thresholds and scores as well as their generation and calibration, and he must have the corresponding knowledge. The anti-money laundering officer must know the capabilities and limitations of the DP system in order to assess whether and how new requirements can be implemented. The final technical implementation can be done by specialized staff or by external service providers.

Selection of the Data Processing System:

If the criteria specified by law are met, the credit institutions are basically free to choose the DP system they wish to use. The fact that there are no system specifications underlines the statement under 6.2.6 that the market must be analyzed intensively when a new system is introduced and that not only specialist but also technical knowledge is required for this.

The conditions under which the use of a DP system can be dispensed with have now also been specified. Section 25h (2) Sentence 1 of the German Banking Act (KWG) provides for a general use of DP systems for all credit institutions, but allows BaFin to define appropriate exceptions. This has now been done under item 6.2.7 AuA BT.

A credit institution may refrain from using a DP system if there is only a small number of contracting parties/beneficial owners or transactions which can be monitored effectively without a DP system. BaFin specifies a balance sheet total of less than EUR 250 million as a benchmark.

Outsourcing abroad:

Under 6.2.8, it is specified that outsourcing to a third party with its registered office abroad is possible, but only if the third party's branch is not located in a high-risk third country.

With regard to outsourcing, it should be noted that outsourcing (domestic or foreign) does not allow the credit institution to outsource the obligation under the Anti-Money Laundering Act. The responsibility for fulfilling the security measures remains with the obliged entities. In this regard, BaFin states under 6.2.8 of the AuA BT that it must be ensured that the anti-money laundering officer has access to all hits and that he is informed immediately of relevant hits so that the time limits for submitting suspicious activity reports are met. Thus, even after outsourcing, a knowledgeable person must be present in the credit institution.


Selecting the right or suitable system is not an easy task and poses problems for many institutions. The present concretization of BaFin concerning the appropriateness of DP systems can be used for the selection and is helpful for the examination of suitability. On the other aspects of a selection procedure, the methods or instruments, there is no concretization. I therefore recommend documenting the selection process and the decisions made in order to minimize the scope and possible consequences of an incorrect selection.



With the Transparency Register and Financial Information Act (TraFinG), the German legislature transposes the applicable EU Directives (EU) 2015/839 (Money Laundering Directive) and (EU) 2019/1153 (Financial Information Directive) into German law.

The conversion of the transparency register from a backup register [1] to a full register and the EU-wide interconnection of registers are intended to enable a fast and simple communication between the member states and Europol. For this, the EU stipulates the use of structured data records in a uniform data format at country level.

The transparency register has been in existence since October 1, 2017. Legal entities under private law and registered partnerships pursuant to §§ 18 et seqq. German Anti-Money Laundering Act (AMLA) are obliged to obtain information on the beneficial owner[3] pursuant to § 19 (1) AMLA, to retain it, to keep it up to date and to immediately notify the register-keeping office for entry in the electronically-maintained transparency register. The objective of the transparency register and its EU-wide interconnection is to combat money laundering and terrorist financing, to create transparency with regard to beneficial owners and also the joint use of account and financial information for the purpose of preventing and prosecuting serious crimes.[4]

The previous backup register

Due to the so-called "fiction of notification" according to § 20 Section 2 AMLA, the previous backup register did not contain complete data records but referred to a different subject register (commercial register, register of persons, etc.) with information on or documents about the beneficial owner, depending on the data situation. In these cases, no separate entry in the transparency register was necessary until now. This was only obligatory if no information was contained in the registers listed in § 20 Section 2 AMLA. Since the data used and stored in the respective registers was not available in a uniform data structure, it could not be used for the interconnection of the transparency registers according to the EU Directive. 

Changes due to the conversion into a full register 

General changes

Due to the conversion into a full register, legal entities pursuant to § 20 Section 1 AMLA, legal persons under private law and registered partnerships as well as foundations without legal capacity pursuant to § 21 AMLA must now not only identify their beneficial owner but also explicitly report it to the transparency register due to the fiction of notification superseded in the TraFinG. The accuracy of the data is henceforth the responsibility of the respective legal entities. Misrepresentations, failure to comply with the obligation to notify and update of the data will be punished by the Federal Office of Administration (BVA) as administrative offenses. It remains to be seen whether § 17 OWiG (German Administrative Offenses Act) will be relevant for the amount of penalties in these cases and what the consequences of the sanctions will be. The notification obligation became effective in the form of the TraFinG on August 1, 2021, but there are transitional periods depending on the legal form in which the periods for the upcoming first-time reports are staggered.[5]

Changes for obligated parties pursuant to § 2 AMLA

For obliged parties pursuant to § 2 AMLA, § 11 Section 5 AMLA new[6] stipulates that the collection of information on beneficial owners in the case of new customers and/or initial contacts "shall be carried out by the contracting party or, if applicable, by the person acting on behalf of the contracting party". Another change relates to already existing business relationships. Pursuant to §12 Section 3 Sentence 3 AMLA new, the duty of verification is satisfied with the inspection of the transparency register, provided that the information there corresponds to the information collected pursuant to § 11 Section 5 AMLA new. If there are doubts about the accuracy of the data and/or the identity of the beneficial owner, further identification measures must be taken. This leads to a considerable saving of time and greater efficiency in the verification of existing business relationships. 

Changes for listed companies

Listed companies were previously exempt from the notification obligation, but this changes with § 3 Section 2 Sentence 5 AMLA new. In the future and like other legal entities, listed companies must also report their beneficial owner to the transparency register according to the existing guidelines of § 3 AMLA.

Changes for associations based abroad in the case of share deals

Due to an amendment to § 20 Section 1 AMLA, associations with registered offices abroad shall also be obliged to report their beneficial owners to the German Transparency Register if they simultaneously obtain ownership rights to a domestic property pursuant to § 1 Section 3 Gewerbesteuergesetz (GrEStG (German Trade Tax Act)) by means of a so-called share deal, i.e. by acquiring shares in a domestic company.

Implementing agencies at federal level

The Federal Gazette Publisher (Bundesanzeiger Verlag) is responsible for maintaining the register. Following the EU Directive requirement, the German Federal Office of Justice (Bundesamt für Justiz (BfJ)) and the German Federal Criminal Police Office (Bundeskriminalamt (BKA)) are designated by the German Federal Government for account retrieval and account data exchange with Europol. The BKA is also the central office for the EU-wide exchange of financial information and available for the access to the exchange of information with the German Central Financial Transaction Investigation Authority at federal level.[7]


The conversion of the backup register into a full register is generally regarded as a positive step towards a more effective fight against money laundering and terrorist financing, but even after the introduction of the TraFinG, questions remain regarding its effectiveness and sustainability.

The effectiveness of the interconnection of the European transparency registers with regards to data quality must be critically questioned. The transparency registers of the individual member states must consist of uniform, structured data records according to the EU Directive, but the individual national legislations are not based on uniform requirements for the data collection of beneficial owners. To this end, an EU-wide regulation on the collection of beneficial owner data should be introduced so that every EU member state has the same standard in the data collection process and to increase the data quality of the transparency registers.

In addition, the register-keeping body does not verify the content of the reported data, so that false reports are more or less only noticed by chance, for example through discrepancy notifications. According to the "Transparency Register – Questions and Answers to AMLA of 09 February 2021", these discrepancy notifications must be submitted by obligated parties pursuant to § 2 Section 1 AMLA and some authorities via the website of the transparency register. Discrepancies exist if the own findings on beneficial owners differ from the data entered in the transparency register. In practice, this will rarely be the case especially in the case of beneficial owners that are considered as being critical. Accordingly, consistently misstated data cannot be identified if, for example, a legal entity, which is subject to the notification obligation, reports an incorrect beneficial owner to the transparency register and reports the same information to an obliged party in the course of establishing a business activity. Since the obligated party is responsible for the identification and the ongoing verification of the accuracy of the data on the beneficial owner, these do not represent a discrepancy with the transparency register in the example given and therefore do not lead to a discrepancy notification.

Transactions with contractual partners with nested corporate structures abroad entail an increased risk per se. It is precisely such structures that conceal the actual beneficial owners very well, so that it is difficult to uncover them even in the course of a sound analysis. The interconnection of the transparency registers supports the identification of beneficial owners, which are already difficult to identify, only to a very limited extent, as § 3 Section 2 Sentence 5 AMLA states: "If no beneficial owner can be identified after comprehensive checks have been carried out, the legal representative, the managing shareholder or the partner of the contracting party shall be deemed to be the beneficial owner.” This means that it will not be less difficult to identify persons, which could not be identified by the obligated parties and other legal entities so far, even with the reporting obligation in place, so that possibly only the so-called fictitious beneficial owners are reported again in particularly difficult cases. Thus, the identification of the beneficial owner remains unresolved, both in terms of the problem and the methodology. Only the ongoing audit requirement of the obligated parties to examine the full register is facilitated and time is saved. The significantly greater effort and thus also the greatest risk in the form of the "initial identification" of the beneficial owners remains unaffected by the conversion to a full register.

Despite the weaknesses listed above, the ultimate effectiveness of the EU-wide interconnection of the transparency registers will become clear after the first round of evaluation, when the first figures and cases are published by the responsible EU and German federal authorities.



[1] A backup register "backs up" data (in our case data on beneficial owners) that are not listed in any other subject register. Thus, only sporadic data are available in the backup register, including references to other registers. Only if data are not entered into any other register it must be listed in the backup register. Therefore, the backup register only contains data on beneficial owners that are not entered anywhere else.

[3] Who is subject to the term beneficial owner is governed by § 3 AMLA.

[4] Compare BT Drucksache (printed document) 19/28164 p. 30.

[5] If no natural person is identified as beneficial owner, the fictitious beneficial owner is reported to the transparency register pursuant to § 3 Section 2 Sentence 5 AMLA. This has been confirmed by the Bundesverwaltungsamt’s (BVA (German Federal Office of Administration)) "Questions and Answers on the Money Laundering Act", as of 09.02.2021.

[6] AMLA new refers to the amendments to the AMLA that already became effective in the course of the introduction of the TraFinG.

[7] Compare BT Drucksache (printed document) 19/28164 p. 2.



Authorities and financial institutions (FIs) are highly aware of the challenge of detecting financial crime. Modern criminals are using increasingly more complex structures and are acting across multiple financial institutions and jurisdictions. Parties, such as FIs, FIUs , and law enforcement, operating alone encounter challenges in the identification and tracing of suspicious behavior. Therefore, collaborative information sharing among private organizations (e.g., FIs) and public authorities (e.g., FIUs, law enforcements, and regulators) is needed in order to detect highly networked activities in money laundering, terrorist financing, or consumer fraud (domestic and global).

However, the crucial point in sharing customer and transaction data is the restrictions imposed by data privacy laws. The protection of privacy and the individuals’ right to control their personal information are a core value of modern society, which is why every institute has to ensure that the stored data is kept confidential and secured. The question is, how can we solve the dilemma of analyzing data across multiple participating organizations and protecting it at the same time? One central and promising approach is the so-called privacy-enhancing technology (PET), which aims at enabling participants to analyze and share data without disclosing any sensitive personal information.

Going one step further, one has to ask how the appliance of privacy preserving analytics can be used to tackle financial crime. This question has been observed by the Future of Financial Intelligence Sharing (FFIS) program. In January 2021, the FFIS published an Innovation and Discussion Paper , which analyzes how cryptographic technology can be of use in the detection of financial crime. Having tested 10 different PET providers in a case study, the FFIS delivered insights into the status of development, capabilities, and challenges of this technology.

The tested technologies are based on decryption and allow the requesting party to send a query to a data owner without disclosing it. The execution of the computations takes place in encrypted format and the results will not be decrypted before they are sent back to the requestor’s own trusted environment. Therefore, neither sensitive data is shared with the requestor nor are the sensitive query parameters shared with the data owner. Also, it is important to mention that PET providers use different functionalities and work in different parts of the compliance world. Some of them can work together, others are rather isolated.

Technology Capabilities & Challenges
Privacy-enhancing technology can be used to check external sets of data in order to gain new information about matching customer profiles, transactions, or Suspicious Activity Reports (SARs), and helps to detect discrepancies in the client reference data (e.g., via reports). This can lead to identifying differences in data, setting indicators of discrepancy detection, detecting suspicious behavior, or even generating a set of reference data for the market.

The collaboration in transaction analysis can be useful to analyze the payment behavior and to identify “risky money flows” through different financial institutions while performing computations. Furthermore, the aggregated information can help to detect unusual behavior among different participants. Ideally, this would be used in the future to also collaborate cross-border.

The capabilities of this technology reach up to machine learning on a group wide approach across different countries. Data from subsidiaries of a group in non-domestic countries can be incorporated for a machine learning algorithm without sharing the underlying data. This approach could even be applied within different parties who want to enrich their machine learning capabilities with combined data.

Not only the private sector but also the above-mentioned public entities and public private partnerships (e.g., AFCA in Germany, JMLIT in UK, or APPPI in Austria) can benefit from this new technology. Using a platform to connect data bases across a network of financial institutions generates a bird-eye-view and helps to identify suspicious patterns.

All in all, it is easy to see how PETs are offering a great potential in new technology which can help public and private participants to act more efficiently against financial crime. Also, PETs constitute a valuable approach for future collaborations in this fight. That is why FFIS has a point in analyzing this option on a long-term basis as criminal organizations with complex global structures have to be faced with collaborative power to detect suspicious behavior.

Still, there are many obstacles to overcome. The acceptance and the usefulness in the market is depending on many factors. Some of the key challenges are the technical complexity, the data quality, and the interoperability. FIs are already facing challenges in their internal IT infrastructures – it might be even more difficult to harmonize systems across different FIs and to support the exchange of data between private and public sectors. In addition, the costs (e.g., computational, operational, or hardware) can be tremendous, as well.

Even more critical is the legal uncertainty. Due to the high regulatory risk – there is practically no regulatory acknowledgement or guidance – companies are afraid to adopt PETs. This causes a great deal of uncertainty in the market and prevents companies from investing.

It is clear that the development of PETs cannot go without a general standard, a legal framework, and an appropriate governance, preferably transnationally harmonized for private and public collaboration. There is a need for a common regulatory approach, coordination, and guidance since the exchange of data and protection of privacy can no longer be governed separately. We need the authorities and the standard setters (e.g., FATF, Wolfsberg Group, and Egmont Group) to act quickly and to guide the development of the global fight against financial crime into the right direction. With around 10 FFIS in the EU block, the EU might be well equipped with experiences to play a leading role in this discussion. For a global approach, it would also be beneficial to include the US in this discussion and to benefit from the experiences of the US FinCEN Exchange.

Nevertheless, there are already steps taken in the right direction, which provides hope. The president of the Financial Action Task Force (FATF), Dr. Marcus Pleyer, has realized the potential of this new technology and emphasizes the need of collaboration in the public and private sector. At present, the necessity for new AML regulations constitutes a discussing point in European circles. Within the FIUs, information sharing is already common practice (e.g., multi-lateral agreements, and information sharing based on goAML) and the key for an effective detection of financial crime and legal prosecution. For instance, the Egmont Group uses a system – Egmont Secure Web (ESW) – which allows a better and secure communication among FIUs worldwide.

In summary, it can be stated that secure data exchange already exists, it just needs more attention and investment. The journey has just started and the day when PETs will play a key role in the anti-financial crime detection does not seem far away anymore. Let’s hope the regulators and the standard setters take their place quickly to support privacy-enhancing technologies. The framework needs to be created to modernize the financial crime investigations and to keep up with the technological capacities of bad actors.

Let us stay tuned on how to make information exchange easier whilst staying GDPR compliant.