Back to the blog

AML Automation in Poland: When Manual Monitoring No Longer Scales

A practical guide to AML automation for obliged institutions: monitoring risks, spreadsheet limits, tool selection, implementation, and human oversight.

AI

Key terms to know

Before getting into the details, it helps to clarify the terminology. This article uses abbreviations and terms with specific legal meanings.

Term Explanation
AML Anti-Money Laundering: the system of legal obligations designed to prevent funds derived from crime from entering circulation.
KYC “Know Your Customer”: the process of identifying and verifying a customer’s identity before establishing a business relationship. See our guide to KYC.
GIIF The Polish General Inspector of Financial Information, the authority responsible for supervising Poland’s AML system.
AMLRO The Anti-Money Laundering Reporting Officer responsible for implementing AML obligations at an institution. This role is appointed from among the members of the management board.
Obliged institution An entity on which the Polish AML Act imposes anti-money-laundering duties, including banks, fintechs, cryptocurrency exchanges, currency exchanges, and accounting firms. See which businesses have an AML implementation obligation.
Customer due diligence measures The set of actions an obliged institution must apply to customers: identification, verification, risk assessment, and ongoing monitoring.
PEP A politically exposed person, a customer who requires enhanced monitoring.

When does manual AML start to create risk?

The Polish Act of 1 March 2018 on Counteracting Money Laundering and Terrorist Financing does not set a number of customers or transactions above which you must implement an IT system. It uses a risk-based approach: your business assesses whether its processes are adequate to its scale.

The Polish Financial Supervision Authority (KNF) is more specific in its guidance for National Payment Institutions. Where there is a “significant number of transactions,” ongoing analysis should use IT programs with appropriate rules for identifying potentially suspicious transactions. “Significant number” has no numerical definition, deliberately. The supervisor expects each institution to set its own threshold, but also expects automation once it reaches a certain scale.

A judgment of the Warsaw Regional Administrative Court (WSA) of 10 August 2021, case V SA/Wa 2574/21, confirms the proportionality principle: AML measures must be proportionate to the nature and size of the obliged institution. Growth in scale calls for more advanced tools.

Four types of risk that grow with scale

Risk type What it means for manual AML Consequence
Regulatory non-compliance Failure to meet the ongoing-monitoring obligation. Administrative penalties and GIIF proceedings.
Operational Human error, delays, and inadequate records. Failure to meet the seven-day reporting deadline.
Workforce AML team overload, burnout, and fatigue-related mistakes. Breach of employer obligations under the Labor Code.
Reputational Failure to detect money laundering. Loss of customer trust and public sanctions.

KNF also treats an obliged institution’s IT tools and systems as a risk factor in its institutional risk assessment. Inadequate IT tools can raise your company’s risk rating even if no incident has occurred.

You reach the critical point when customer and transaction volumes exceed what AML staff can reliably review while observing working-time limits. In banking, daily transaction volumes run into the hundreds of thousands, making it impossible to manually compare every customer’s profile with every transaction. The same mechanism applies in fintechs and cryptocurrency exchanges, but the threshold arrives earlier than you may expect. If your company is growing and the AML team cannot keep up, contact us. We can help assess whether your processes remain adequate to your scale.

What must ongoing AML do, and why a spreadsheet is not enough

Article 34(1) of the Polish AML Act defines customer due diligence measures, including ongoing monitoring of the business relationship. GIIF Communication No. 22 explains that this monitoring includes analyzing transactions to ensure they are consistent with what the institution knows about the customer, examining the source of funds or assets, and keeping documents and data up to date. This is not a one-time onboarding check. It continues throughout the customer relationship.

Seven requirements a spreadsheet cannot meet

  1. Near-real-time transaction monitoring. A spreadsheet does not “see” new transactions; someone must enter them manually. With hundreds of transactions per day, delays grow from hours to days.
  2. Sanctions and PEP list integration with fuzzy matching. Sanctions lists change dynamically. A spreadsheet cannot automatically compare customer names against current lists or account for transliteration and spelling variants.
  3. Change tracking and reconstruction of what was known at a given time. GIIF Communication No. 45 says that a change in a customer’s circumstances, such as a management change, a new owner, or a new transaction type, may trigger an updated risk assessment. A spreadsheet does not record who changed what and when. A user can overwrite a formula or delete data without this being detectable months later.
  4. GIIF reports in the required XML formats. Article 72 of the AML Act requires reporting transactions exceeding the equivalent of EUR 15,000. XML schemas published in the central repository of electronic document templates are the reporting standard. A spreadsheet does not natively generate those files.
  5. Integrated risk management for the institution and its customers. KNF requires risk categories of low, normal, high, or unacceptable, with review schedules based on the risk level. New European standards state that reviews should take place at least annually for high risk and at least every five years for normal and low risk. Manually tracking these dates for hundreds of customers is impracticable.
  6. Alert management. Alerts need to be assigned to an analyst, tracked by status, and recorded with the resulting decision. KNF says transaction-analysis rules should be updated and each alert analysis archived. A spreadsheet does not provide an alert workflow.
  7. Automated data retention under AML rules. Documents must be retained for at least five years after the business relationship ends; GIIF may extend this by another five years. A spreadsheet does not automatically limit retention or provide access controls that meet GDPR requirements.

GDPR requirements that are easy to overlook

A decision by Poland’s Personal Data Protection Office (UODO) concerning a bank showed that scanning identity documents is lawful in the AML context only when it is connected to the necessary application of customer due diligence measures. A bank that scanned documents in situations unrelated to its AML duties received a substantial fine.

A spreadsheet does not distinguish the context in which data is processed. It does not provide data minimization, purpose limitation, or the accountability required by GDPR.

Common manual-monitoring errors and their consequences during an inspection

GIIF inspections are initiated after the obliged institution receives prior notice. Between delivery of the notice and the start of an inspection, only 7 to 30 days pass. That is little time to organize records that should have been complete all along.

KNF decision concerning Credit Agricole Bank Polska S.A.

KNF imposed a total fine of PLN 1,000,000 on Credit Agricole Bank Polska S.A. for violations that included:

  • Failing to prepare a risk assessment in a way that identified and assessed money-laundering risk, in breach of Article 27 of the AML Act.
  • Failing to apply customer due diligence measures to identify the beneficial owner, in breach of Articles 33 and 34 of the AML Act.
  • Failing to properly monitor the customer’s business relationship through transaction analysis and document updates.

The bank did not appeal to the court, which the source describes as confirming acceptance of the supervisory findings.

Supreme Audit Office report for 2022 to 2024

The Supreme Audit Office (NIK) assessed the effectiveness of Poland’s AML/CFT system as insufficient. Poland ranks among the ten European countries with the highest risk of money laundering and terrorist financing. NIK recommended, among other things, intensifying work on GIIF’s IT System 2.0 and implementing the goAML application.

Four groups of errors most often identified during inspections

Error group Example Legal basis
Risk-based approach Relying only on historical data without considering changes in the customer’s profile; accepting transactions far above previous levels without deeper analysis. Article 27 of the AML Act.
Ongoing transaction analysis Superficial analysis limited to amount, counterparty, and date, without assessing economic context; failure to examine the source of funds or assets. Articles 43(3) and 43(4) of the AML Act.
Records Fragmentary records without references to specific data; inconsistencies between systems and registers. UKNF position.
Training One-off training without regular updates; programs that are too general and theoretical; employees training one another without any external training. Article 52 of the AML Act and GIIF Communication No. 92.

GIIF says that accepting brief customer explanations that do not allow the institution to genuinely understand the customer’s activity does not amount to properly applying customer due diligence measures. If the institution cannot produce records showing that it performed an analysis, inspectors may conclude that the duties were not performed, whether or not an analysis actually took place.

Training duties also matter. GIIF Communication No. 92, UKNF, and the National Bank of Poland (NBP) specify that AML/CFT training covers everyone performing AML/CFT duties: employees, civil-law contractors, agents, and board members. Employees may not train one another within the same institution if none of them has completed external training.

Criteria for choosing an AML automation tool

Polish law does not provide a list of “certified” AML/KYC IT tools. Selection criteria follow indirectly from obliged institutions’ duties and supervisory expectations. The points below are worth checking.

Functional criteria

Category Requirement Why it matters
Risk assessment and KYC Assign risk categories to customers and transactions, with review schedules based on risk. KNF requires categorization as low, normal, high, or unacceptable.
Identity verification Integrate with the National Court Register (KRS), the Central Register and Information on Business Activity (CEIDG), and the Central Register of Beneficial Owners (CRBR); screen sanctions and PEP lists with fuzzy matching. The CRBR register is explained here. Beneficial-owner identification duties under Articles 33 and 34 of the AML Act.
Transaction monitoring Define detection rules, aggregate related transactions around the EUR 15,000 threshold, and link monitoring intensity to the risk category. Article 72 of the AML Act requires reporting above-threshold transactions.
Reporting Generate XML files that follow GIIF schemas and report within seven days. Article 78 of the AML Act and the central repository of templates.
Video verification Securely transmit image and sound, recognize identity documents, and record the session. KNF position of 3 May 2022.

Security and audit criteria

  • Access controls with defined roles, such as AML analyst, AMLRO, manager, and auditor, and permissions assigned to specific functions.
  • Complete activity logs showing who viewed, changed, or approved which data, and when.
  • Automated data retention that manages the five-year period, which may be extended to ten years.
  • GDPR compliance, including data minimization, purpose limitation, integrity, confidentiality, and accountability.
  • The ability to reconstruct what the institution knew about a customer at a particular point in the past.

Important caveat: automation does not replace human judgment

The European Banking Authority (EBA) confirms that AML is the most product-mature area of RegTech, with many solutions on the market. However, commentary on the AML Act points to a less-discussed risk: analysts may rely too heavily on recommendations from AI tools rather than on their own knowledge and experience. A tool automates repetitive work and organizes data. A person decides whether to report a transaction to GIIF.

How AMLtrack connects procedures, monitoring, and records

AMLtrack combines legal guidance and technology. It guides the team through AML steps instead of leaving every decision to individual interpretation.

What AMLtrack does in an AML team’s day-to-day work

  • Customer verification: automated checks against KRS, CEIDG, CRBR, sanctions lists, and PEP lists.
  • Risk assessment: assign risk categories using defined criteria and set review schedules automatically.
  • Transaction monitoring: ongoing analysis using detection rules and aggregation of related transactions.
  • Records and archiving: a full audit trail, with each decision, change, and review recorded and available for inspection.
  • Reporting: generate documents in the formats required by GIIF.

This gives the AMLRO a complete, current picture of customer risk and activity without having to compile information from several spreadsheets, folders, and email inboxes.

Transition plan: from a manual process to a working system in four stages

Automating AML does not have to mean a revolution. This plan moves from a manual process to an automated system without interrupting ongoing business.

Stage I: diagnosis and mapping (2 to 4 weeks)

  • Review current AML procedures: customer onboarding, transaction monitoring, reporting, and archiving.
  • Identify gaps between actual practice and AML Act requirements and KNF guidance.
  • Assess scale: customer count, transaction volume, alert count, and AML team workload.
  • Map data flows: where customer and transaction information comes from, where it is stored, and who can access it.

Stage II: design the target model (2 to 3 weeks)

  • Define the target AML/KYC process model, including risk categories, review schedules, and detection rules.
  • Select a tool using the functional, security, and audit criteria above.
  • Define system roles and permissions: who analyzes alerts, approves decisions, and reports to GIIF.
  • Plan integrations with existing systems, including transaction systems, CRM, and public registers.

Stage III: implementation and migration (4 to 8 weeks)

  • Configure the tool: detection rules, risk categories, review schedules, and report templates.
  • Migrate customer data from existing sources, such as spreadsheets, folders, and systems.
  • Train the AML team under Article 52 of the AML Act and GIIF Communication No. 92. Training must cover everyone performing AML/CFT duties.
  • Run the old and new systems in parallel during a transition period to verify data and processes.

Stage IV: maintenance and improvement (ongoing)

  • Monitor system effectiveness: whether alerts are appropriate and detection rules need calibration.
  • Update the institution’s risk assessment at least every two years, under Article 27 of the AML Act.
  • Provide regular team training tailored to legal changes and new types of threats.
  • Review and update internal procedures in response to regulatory changes, new GIIF communications, and KNF positions.

Automating AML processes is a legal, technological, and organizational decision. Buying a tool is not enough: it must be embedded in procedures that comply with the AML Act, adapted to the business model, and supported by team training.

We support fintechs, payment institutions, and cryptocurrency exchanges in organizing AML processes, from an audit and risk map through implementation of an AML system with AMLtrack to ongoing support and monitoring of obligations. Each element is tailored to the business model and organizational scale. Our work covers the implementation of AML procedures.

We combine legal advice with technology. AMLtrack guides the team through decisions step by step rather than leaving them open to interpretation. Management gets visibility and control, and the team gets clear instructions.

If your business is growing and manual AML monitoring is creating risk rather than reducing it, contact us. We can plan a transition to automation without stopping your operations.

Summary

Manual AML works at a small scale. As customer and transaction volumes grow, spreadsheets, folders, and emails stop meeting AML Act requirements: they do not provide ongoing monitoring, access controls, XML reporting, or a full audit trail.

KNF expects automation once an institution reaches a certain scale. NIK considers Poland’s AML system insufficiently effective. Administrative penalties, such as the PLN 1,000,000 fine imposed on Credit Agricole Bank Polska S.A., show that supervisors enforce these duties.

Moving to an automated system need not be a revolution. Four stages, diagnosis, design, implementation, and maintenance, help organize processes without interrupting business. Start by auditing current processes and deciding whether they remain adequate for your company’s scale.

Frequently asked questions

Does the AML Act set a specific customer threshold above which an IT system is required?
No. The Act of 1 March 2018 on Counteracting Money Laundering and Terrorist Financing uses a risk-based approach. Each obliged institution assesses whether its processes are adequate. KNF guidance for National Payment Institutions says that ongoing analysis should use IT programs when there is a “significant number of transactions,” but it does not define that number. A WSA judgment of 10 August 2021, case V SA/Wa 2574/21, confirms proportionality: AML measures must be proportionate to the nature and size of the institution.

What penalties may follow from AML monitoring errors found during an inspection?
Administrative penalties may reach EUR 1 million. KNF fined Credit Agricole Bank Polska S.A. PLN 1,000,000, including for failure to properly monitor customer business relationships. The Ministry of Finance maintains a public page with information about penalties. In addition to fines, an institution may receive post-inspection recommendations it must implement and face a repeat inspection after serious violations.

How long must AML records be kept, and can a spreadsheet meet the archiving requirements?
The AML Act requires documents and information to be kept for at least five years from the end of a business relationship or the date of an occasional transaction. GIIF may extend that period by another five years, up to ten years in total. A spreadsheet does not provide automated retention, access controls with activity logs, or GDPR-compliant limits on storage.

How long does it take to move from manual AML monitoring to an automated system?
With appropriate planning, 10 to 17 weeks, depending on scale and process complexity: diagnosis and mapping take 2 to 4 weeks, target-model design takes 2 to 3 weeks, and implementation with data migration and team training takes 4 to 8 weeks. Ongoing maintenance and improvement follow.

Does AML automation mean that I no longer need an AML team?
No. Automation organizes repetitive work, including sanctions screening, transaction aggregation, review-deadline tracking, and XML report generation. A person still decides whether to report a transaction to GIIF. Commentary on the AML Act highlights the risk of analysts relying too heavily on AI recommendations: the tool supports, but does not replace, human judgment and experience.

Must a small obliged institution, such as an accounting firm, also automate AML processes?
Not necessarily. With low transaction volumes and direct customer relationships, manual AML may be adequate. Proportionality works both ways: a small institution need not use measures at the same level of detail as a bank. But business growth can make existing methods inadequate, so periodically check whether your processes still match your scale.

RECOMMENDED

You may also be interested in

Selected examples of projects in which we supported businesses on legal matters, from regulatory and compliance advice to technology projects, transactions and day-to-day business support.