In its recently published Annual Report 2020, the German FIU also addressed the issue of Trade-Based Money Laundering (TBML). It presents two case constellations as examples which are quite common in the international context and may be assumed as already known typologies by the obliged parties under the German Money Laundering Act (GwG). Nevertheless, the examples show that such situations require a high degree of manual control activities and pose great challenges for the obliged parties.

The FIU points out that trade-based money laundering has increasingly become the focus of anti-money laundering in recent years and that it is one of the three main methods of money laundering. So far, this very complex topic has not reached the status in the German banking industry that it already has in other countries, such as the USA, Singapore, South Africa or India.

However, it can be assumed that this understanding will change in the short or medium term. On 8 June 2021, the German Federal Financial Supervisory Authority (BaFin) explicitly addressed the topic of "trade finance" in point 8 of the publication of the Interpretation and Application Guidelines for credit institutions (special section). It also refers to the information in the First National Risk Analysis and the risk factors of the European Banking Authority (EBA).

EBA ML TF Risk Factors Guidelines

The reference to the fact that obliged parties have already been confronted with corresponding typologies in the past by the FATF, the Asia Pacific Group on Money Laundering and the Egmont Group is a first logical step towards raising awareness of TBML. Beyond that, however, serious publications, such as the Wolfsberg Group's standards published in 2019, can also inform in that field

Wolfsberg Group Trade Finance Principles

and be an important medium for obliged parties. With the help of these documents, obliged parties have the opportunity to review the risk assessment, update it if applicable and check the effectiveness of the necessary measures. The typologies communicated by the German Federal Criminal Police Office (BKA) in the past only capture the risk partially. They did not deal with the complexity of the topic in the depth that seems necessary. Money laundering officers often face the challenge of dealing with the therein described, partly very abstract risks and, based on them, deriving suitable processes and measures.

Since trade finance, insofar as it is a documentary transaction, already begins with the initiation of the trade, it also makes sense, as outlined in the Wolfsberg Group publication, to examine the processes already implemented, adapt them where necessary, evaluate them and review them on a regular basis. This way, the type of trade, the volume of the trade, the type of goods and ultimately the agreed price can already provide important indicators for the risk of the trade - not with regard to the default/credit risk, but certainly with regard to the risk of being abused for the purpose of money laundering. In this respect, the initial risk assessment from within the trade should already be given enormous importance. However, BaFin has also stated that the entire process should be carried out in a risk-oriented manner. In this respect, the institutions have a certain flexibility here. It remains to be seen how these will then be evaluated in the context of the continuous examinations.

For the daily monitoring by the research systems implemented in the institutions, this means that it must generally be checked whether all relevant data are completely transferred to the systems. The business rules must be tested and their effectiveness revised or adjusted accordingly. Classic money laundering typologies such as documentary business in round sums or "one to many" or "many to one" should be integrated into the set of rules for trade finance in the future. In addition, the aforementioned typology papers can be an important source of information and help obliged parties implement the necessary processes and measures.

It remains important that the FIU regularly informs obliged entities about new methods and trends in the area of Trade-Based Money Laundering. Organised crime is and will continue to be extremely creative when it comes to finding new ways to channel incriminated funds into the legal economic cycle. 



On August 19, 2021, the Central Customs Authority published the Financial Intelligence Unit (FIU) Annual Report for the reporting year 2020, which aims to provide information on which economic sectors in Germany are particularly under the influence of (financial) criminal activities.

From the perspective of msg Rethink Compliance, the following topics play a special role in the annual report:

  • Obligation of additional professional groups (DNFBPs - Designated Non-Financial Businesses and Professions)
  • Trade-based money laundering
  • Hawala banking
  • COVID-19
  • International cooperation
  • Other observations

In our #rethinkcompliance blog, we will take a closer look at these topics in six parts. In today's blog, we first refer to the obligation of additional professional groups. 

Obligation of Additional Professional Groups

Following the first National Risk Analysis 2018/2019, which certified a high money laundering risk for the German real estate sector, the German Regulation GwGMeldV-Immobilien came into force on October 1, 2020. In addition to the real estate sector, it also obliges legal advisory professions, such as notaries, lawyers, auditors and tax consultants, to submit suspicious activity reports to the FIU.

Source: Bundesfinanzministerium - Verordnung zu den nach dem Geldwäschegesetz meldepflichtigen Sachverhalten im Immobilienbereich

As a consequence, it is not surprising that the number of suspicious activity reports from this circle has increased by leaps and bounds, especially among the professional group of notaries.

While there had been an increase of over 100% when comparing 2018 to 2019 (note: 8 SARs were submitted in 2018, and a total of 17 in 2019), there were a total of 1,629 reports to the FIU in 2020. It will therefore be interesting to observe whether this trend will continue in the following years and then remain at a high level.

FIU Jahresbericht 2020 Verdachtsmeldungen nach Verpflichteten Gruppen

Figure 1: Number of SARs by obligor group (Source: FIU Annual Report 2020)

The topic of money laundering is not entirely new for notaries. The Federal Ministry of Justice already drew attention to this in 2004. The publicly accessible study about the vulnerability of lawyers, tax consultants, notaries and auditors through money laundering („Gefährdung von Rechtsanwälten, Steuerberatern, Notaren und Wirtschaftsprüfern durch Geldwäsche“)

 BMJ 2004 Gefährdung von Rechtsanwälten Steuerberatern Notaren Wirtschaftsprüfern

aimed at sensitising this professional group to the issue by means of specific cases. However, it first required a legal regulation to ensure that notaries also need to submit suspicious activity reports to the FIU from now on. For example, a report must be made if contracting parties come from risk countries or if the overall circumstances of the purchase price settlement do not appear conclusive. This is the case, among others, if there is a blatant disproportion between the purchase price and the known assets of the clients. With regards to the definition of a risk state, there is certainly still a need for clarification. To refer only to the list of the EU Delegated Regulation and to the list of countries published by the FATF seems to fall short. For example, the countries used by the so-called "Russian Laundromat" for its financial activities have not yet been recorded here. 

It would be extremely helpful for those obliged under the German Money Laundering Act to know in which cases, for example, the professional group of notaries has submitted suspicious activity reports to the FIU. This should give obliged parties an indication of the typologies with which the banking industry must deal in connection with real estate financing. In the past, the FIU has done important preparatory work in this regard through its newsletters and the indications presented therein to inform obliged parties accordingly.

Overall, the obligation of notaries is a step in the right direction for more effective money laundering prevention. However, this comes very late. In the end, it remains to be said that the explosive increase in notifications appears to be justified and, according to the motto "better late than never", more than necessary. 

It will continue to be important that this group of people is also randomly audited by independent bodies with regards to compliance with the legal regulation. The challenge for auditors will be to first create a catalog of indicators in order to be able to perform standardised audit procedures. 

Following the experience of the notaries' offices, it will now also be interesting to see whether the case numbers of other obliged parties, such as real estate agents or tax consultants, will also show significant increases in the future. 

 FIU Jahresbericht 2020 Verlauf Verdachtsmeldungen nach Verpflichteten Gruppen

Figure 2: Number of SARs by obliged party groups 

We are looking forward to the FIU Annual Report 2021 to find out whether this trend will continue accordingly.



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.