Risk Evaluation Questionnaire (REQ) — Ireland’s AML return
The Risk Evaluation Questionnaire is the return that decides how closely the Central Bank of Ireland supervises you — and since 2025 it is an XML file, not a spreadsheet. The REQ is how the Central Bank builds its risk-based AML/CFT supervisory model: inherent risk on one side, control quality on the other, supervisory priority out the end. It is required under section 22 of the Central Bank (Supervision and Enforcement) Act 2013, now exists in nine sector-specific versions, and the payment and e-money version is a schema-validated XML submission with a hard deadline. This piece covers who files, what the return contains, the format rules that cause rejections, and three worked cases.
1. What the REQ is, and what it is not
The Criminal Justice (Money Laundering and Terrorist Financing) Act 2010 — the CJA 2010 — puts the substantive obligations on credit and financial institutions: a risk-based approach, customer due diligence, suspicious transaction reporting, governance, policies, record keeping and training. Financial sanctions obligations arrive separately, through directly applicable EU Council Regulations.
The REQ is not itself one of those obligations. It is the instrument the supervisor uses to see them. It asks three things: what the institution’s business is and what inherent ML/TF/FS risk that creates; how the institution has assessed that risk itself; and what controls it built in response. The Central Bank combines the answers with what it already holds — inspection findings, supervisory correspondence, information from other authorities — and produces the risk rating that drives how much attention the firm receives.
So the REQ is a supervisory input, not a compliance certificate: a clean questionnaire from a firm whose business is objectively high-risk reads as a control claim the supervisor will test. The Central Bank is also explicit that the REQ is not an appropriate channel for the sole communication of a material issue.
2. Nine sectors, nine questionnaires, nine deadlines
The REQ was broadly one instrument until the Central Bank developed sector-specific questionnaires to capture more detailed risk data. Each sector now has its own schema, guidance note and submission date, and each institution must use the XSD specific to its sector.
| Sector | Submission deadline |
|---|---|
| Investment firms | 30 June 2026 |
| Crypto-Asset Service Providers | 31 July 2026 |
| Credit institutions | 4 September 2026 |
| Payment institutions / electronic money institutions | 9 September 2026 |
| Life insurers | 11 September 2026 |
| Credit unions | 18 September 2026 |
| Fund depositaries | 30 March 2027 |
| Fund management companies | 31 March 2027 |
| Fund administrators | 2 April 2027 |
The reference date is 31 December of the preceding calendar year unless a question says otherwise, so the September 2026 payments deadline reports the 2025 position. The Central Bank states that this is a hard deadline and no extensions will be granted. Files appear on the Portal at least two weeks before the date — not enough time to build a generator, so the work starts from the published schema.
3. Who files, and where the group boundary falls
The PI/EMI questionnaire applies to payment and electronic money institutions supervised by the Central Bank. The group rules cause the most confusion.
- Each regulated institution files its own REQ. Where a group contains several institutions regulated by the Central Bank, one return does not cover them all.
- Where the legal structure is reported as Parent_of_group within the EEA, or as Stand_alone_entity, two sections — Business Model and Group-Wide AML/CFT Framework — are aggregated across all the institution’s EEA entities. Everything else is Irish-institution data only.
- Where the legal structure is anything else — a subsidiary, a branch — only data relating to the Irish institution is required.
- For a branch passporting in under freedom of establishment, the ultimate EEA parent is the head office unless the entity belongs to an EEA sub-group, in which case it is that sub-group’s top entity.
This boundary moved recently: version 2.0 of the PI/EMI guidance, dated 10 June 2026, changed the instruction so that the data to include is now only data written from the Irish institution. A firm that built its extraction against the earlier wording is pulling the wrong population, and the schema will not tell it so.
4. What the questionnaire actually asks
The PI/EMI REQ runs to well over a hundred pages of guidance and is organised in two halves plus a set of country-level tables.
- General — legal structure and the ultimate EEA parent (name, LEI, country, AML/CFT supervisory authority), a business-model summary, each of the eight PSD2 activities under Directive (EU) 2015/2366 as a yes/no with an optional comment, integrated crypto-asset services, international presence, and the Statement of Compliance.
- Inherent risk — customer segments and sectors, anonymity, merchant acquiring, money remittance, e-money, payment accounts, currency exchange, virtual IBAN accounts, the crypto blocks, lending, correspondent relationships, deposits and withdrawals, crowdfunding, funding methods and remote onboarding.
- Mitigation and control — business-wide risk assessment, policies, onboarding, offboarding, CDD, transaction monitoring, suspicious alerts and rejections, STRs, sanctions screening, outsourcing, training, assurance testing, audit, governance, the Funds Transfer Regulation and the group-wide framework.
- Country tables — physical presence, beneficial owners, digital accounts, prepaid cards, correspondent relationships, geography of funds flow, transaction monitoring and PEPs, each per country with customer counts, transaction counts and euro values.
The Statement of Compliance deserves separate attention. It asks whether the institution has materially complied with its obligations under Part 4 of the CJA 2010, the Criminal Justice (Terrorist Offences) Act 2005 and financial sanctions regulations over the twelve months covered; if not, a 500-character summary; plus the name, position and PCF status of the signatory. That is a signed regulatory statement inside a data file.
5. The format rules that cause rejections
Only XML submissions are accepted; the Excel version exists solely to support understanding and is not a submission format. Beyond conformity with the published XSD, the Central Bank imposes constraints that a generic serialiser will breach.
- Explicit closing tags for every element.
<A02011 Identifier="CBR" EnumerationYesNo="Yes"></A02011>is accepted; the self-closing equivalent is not. - A fixed wrapper. The declaration
<?xml version="1.0" encoding="utf-8"?>followed by the sector root element with the sector namespace — for payments and e-money,<PIandEMI xmlns="http://www.centralbank.ie/Schemas/AML/2025/A02">. - Strict table order. The taxonomy defines the order in which tables must appear. A file whose tables are complete and correct but ordered differently is rejected.
- Two table structures. Structure A carries REF codes as attributes, one row per enumeration value — a country row, say — with no value repeated. Structure B carries an
Identifierplus the variable name for that data type, with no identifier repeated. - Data types. LEI is 20 characters, with twenty zeros as the documented fallback. Strings are capped at 100, 500, 1,000 or 2,000 characters, limited to printable ASCII plus the euro and pound signs, using the predefined XML entity references for
<,>,&,'and"; empty and whitespace-only values are rejected. Dates areYYYY-MM-DD, decimals run to six places, integers must be non-negative, and percentages are decimals — 4.7% as0.047.
The Portal runs basic validations at upload and the file cannot be submitted until they pass, but further validations follow afterwards and firms are notified of the results. Nor is submission complete until the return has been finalised and signed off — two deliberate steps after the file lands.
6. Worked example — the file that was right and still failed
Facts: an e-money institution generates the REQ from its data warehouse using a standard XML library. Roughly forty fields are legitimately not applicable and carry no value, so the serialiser emits them as self-closing elements. The file validates cleanly against the XSD.
Which rule applies: schema conformity is necessary but not sufficient. The guidance imposes a constraint — explicit closing tags on all elements — that no XSD can express. A file can be schema-valid and still non-conforming.
What the practitioner does: configures the serialiser to emit paired tags, then adds a pre-submission check that is not a schema check: a scan for self-closing elements, a check on namespace and root element, and a comparison of table order against the guidance. Runs it on the Central Bank’s published sample XML first, to confirm the checker passes a known-good file.
Outcome: the XSD and the guidance are two rule sets and the guidance is the stricter one. Teams that validate only against the schema find the gap inside a window with a hard date and no extensions.
7. Worked example — the percentage that passed validation and misreported the firm
Facts: a payment institution onboarded 12,400 natural persons in the reference year, 8,300 remotely, of whom 410 were rated high risk. The analyst fills the remote-onboarding block with 67 and 4.9, reading the field labels as percentages.
Which rule applies: the remote-onboarding fields are PercentageValue — a percentage as a decimal, so 67% is 0.67 and 4.9% is 0.049. The submitted values are valid decimals within six places, so nothing rejects.
What the practitioner does: treats every PercentageValue field as a unit-conversion risk and handles the conversion in one place in the generator, not in the source queries. Derive, do not retype — the same discipline keeps the REQ’s totals consistent with their components.
Outcome: the file is accepted and the firm has reported remote onboarding at 6,700% with a high-risk share of 490%. Nothing objects. An implausible pair of values simply enters a supervisory model whose purpose is to rank firms by inherent risk.
8. Worked example — the generator built against last year’s schema
Facts: a group builds a REQ generator in the first filing cycle and schedules it annually. The following year it emits the enumeration values it learned the first time, including Gov_body for a government-body customer segment, plus question codes its mapping document still lists.
Which rule applies: the PI/EMI package is versioned and the enumerations move. Version 2.0 deleted one block of question codes and added another; version 2.1 changed a customer-segment value from Gov_body to Government_body to match the other files. Earlier revisions added Ireland to the EEA country enumeration, added Kosovo to the country list and corrected a misspelled funding-method value.
What the practitioner does: stops treating the schema as a constant. Pins the package version, reads the technical change log that ships with each release before the cycle opens, and regenerates the enumeration lists from the XSD rather than from a hand-maintained sheet. Keeps the mapping document, but as documentation of where each figure comes from in the source systems — the part that does not change.
Outcome: a deleted question code and a renamed enumeration value both fail at the worst possible moment. Re-pulling the current package is the cheapest control in the exercise.
9. Why this return will matter more
The REQ is no longer a purely national instrument: the Central Bank states that it also covers data points to be collected on behalf of the European Anti-Money Laundering Authority under the technical standards made pursuant to Article 40(2) of Directive (EU) 2024/1640 and Article 12(7) of Regulation (EU) 2024/1620. The same figures will be asked for in every market you operate in — different schemas, different dates.
FAQ
What is the REQ, and under what power is it required?
The Risk Evaluation Questionnaire — the return through which the Central Bank of Ireland collects standardised data on an institution’s inherent ML/TF/FS risk and its AML/CFT control framework, in order to set supervisory priorities. It is required pursuant to section 22 of the Central Bank (Supervision and Enforcement) Act 2013; the underlying AML/CFT obligations sit in the Criminal Justice (Money Laundering and Terrorist Financing) Act 2010.
When is the REQ due for payment and e-money institutions?
9 September 2026 for the reference date of 31 December 2025. The Central Bank states this is a hard deadline and that no extensions will be granted.
How is the REQ submitted, and can Excel be used?
Only XML is accepted — the Excel version is published solely to support understanding. The completed XML file is uploaded to the Central Bank Portal, which replaced the Online Reporting System, and must then be finalised and signed off for the submission to be complete.
Does every entity in a group file separately?
Yes — each institution regulated by the Central Bank submits its own REQ. Only a reported parent of an EEA group, or a stand-alone entity, aggregates the business-model and group-wide sections across EEA entities.
How are percentages entered?
As decimals. 4.7% is entered as 0.047, to a maximum of six decimal places.
Why does a schema-valid file get rejected?
Because the guidance adds constraints the XSD cannot express — explicit closing tags on every element, the fixed namespace and root element, and a strict order in which the tables must appear.
What to do, today
- Download the current sector package — XSD, guidance note, sample XML, change log — and check its version against your generator’s.
- Build a pre-submission checker that is not a schema validator — self-closing tags, namespace and root element, table order, character set, non-negative integers, percentage magnitudes — and test it against the published sample file first.
- Fix the group boundary in writing before extraction: which legal structure you report, which two sections aggregate across EEA entities, which data is Irish-only.
- Route the Statement of Compliance through governance, not the reporting team. Someone is putting their name and PCF status against a twelve-month compliance assertion.
- Map each REQ figure to a source system once, diarise backwards from the deadline rather than forwards from the Portal, and reuse that lineage for the other national AML returns you file.
Related: AML data returns compared — beyond the SAR · The Central Bank of Ireland Portal — PIA, PIS, EIA and EIS returns · The EU AML package — AMLR, AMLD6 and AMLA


