ZVS9 Reporting in Germany: The Bundesbank’s Quarterly Payments Return
Payment service providers resident in Germany are subject to the Deutsche Bundesbank’s quarterly ZVS9 reporting requirements, with returns due by close of business on the last working day of the month after each quarter ends. Qualifying subsidiaries may be covered by a domestic group return submitted by their parent under the Bundesbank’s group-reporting arrangements. ZVS9 reporting delivers Table 9 of ECB Regulation (EU) No 1409/2013 as amended by Regulation (EU) 2020/2011: sent-side payment transactions involving non-PSPs, including qualifying transactions initiated by a PSP where a non-PSP is the payer or payee, broken down by instrument and initiation channel, with MCC breakdowns for electronically initiated card payments where the code is known, and geographic reporting using Geo6 country columns. Since 1 July 2026 the file travels through the Bundesbank’s NExt platform under a naming convention built on the institution’s RIAD code.
The return has 13 position codes. Germany grants no derogations from the ECB regulation, so no size threshold takes a payment institution or an e-money institution out of it. Each pair of quarters also has to add up to the semi-annual ZVS 4 report filed two months later, so a quarter accepted at the end of July is tested again when the half-year figures arrive at the end of September.
Related reading: AnaCredit Reporting in Germany: Bundesbank Credit Data and Deadlines
Legal basis of ZVS9: ECB Table 9 and the Bundesbank’s 2021 instruments
Two layers of law sit behind the return. At EU level, Regulation (EU) No 1409/2013 of the European Central Bank of 28 November 2013 on payments statistics (ECB/2013/43, OJ L 352 of 24 December 2013) originally asked for annual data only. Regulation (EU) 2020/2011 of 1 December 2020 (ECB/2020/59, OJ L 418 of 11 December 2020) replaced Annexes I to III, added quarterly and semi-annual reporting and applies from 1 January 2022.
Annex I of the amended regulation organises the collection into nine tables: Tables 1 to 6 and Table 9 come from payment service providers, Tables 7 and 8 from payment system operators. Table 9, “Quarterly reporting of payment transactions involving non-MFIs”, covers the number and value of payment transactions sent by non-MFIs, compiled by payment service and initiation channel, with card-based transactions further broken down by merchant category code (MCC). Recital 7 gives the purpose: MCC detail and worldwide card coverage feed the balance-of-payments items on travel, transport and e-commerce, hence the quarterly frequency and shorter deadlines. The regulation binds reporting agents in euro-area Member States; Sweden runs its own national collection, described in our Riksbank payment statistics reporting guide.
Article 3(2) leaves the reporting arrangements to each national central bank, and Article 6(2) has the NCB set deadlines that let it meet its own deadline to the ECB. The Bundesbank acted on 27 April 2021 through two instruments, both published in the Bundesanzeiger on 16 June 2021:
- Mitteilung Nr. 8001/2021, a statistical order (Anordnung) for credit institutions within Article 1(1)(a) of Directive (EU) 2015/2366 (PSD2) resident in Germany and for their German-resident branches. It revoked the 2014 order, Mitteilung Nr. 8001/2014, with effect from 1 April 2022.
- Mitteilung Nr. 8002/2021, a determination (Festsetzung) for payment service providers that are not credit institutions, covering providers within Article 1(1)(b) to (f) PSD2 resident in Germany and their German-resident branches. It revoked the 2014 notice for payment institutions with effect from 1 April 2022.
Both instruments attach reporting schemas (Meldeschemata) based on the ECB requirements and require electronic submission in accordance with the Bundesbank’s guidelines (Richtlinien) and individual statements on payments statistics, which pulls the 82-page general guidelines, home of the position definitions and counterexamples, into the obligation by reference. The two instruments differ on national add-ons. Order 8001/2021 additionally mandates national memorandum data for credit institutions, including card-induced direct debits (PDD.5), while the corresponding PDD.5 item under determination 8002/2021 is voluntary. A reporting build therefore follows the annex and mandatory-field rules of the instrument that applies to the reporting institution.
ZVS9 is the last schema in each annex and the only quarterly one. Schema numbers follow the ECB table numbers, and because Tables 7 and 8 belong to payment system operators, there is no ZVS7 or ZVS8.
Guideline (EU) 2021/832 of 26 March 2021 (ECB/2021/13, OJ L 208 of 11 June 2021) is addressed to the national central banks. Its Article 6(1)(b) requires each NCB to verify the consistency between quarterly and semi-annual information, the origin of the cross-frequency checks covered below. The Bundesbank’s own Table 9 deadline to the ECB is the close of business on the last working day of the second month after the quarter, under Article 6(1)(a) of the amended regulation, one month after the reporting agents’ deadline.
Who must report ZVS9: resident PSPs and branches, with no size floor
Article 2 of the amended regulation makes payment service providers, including electronic money issuers, and payment system operators the actual reporting population. The Bundesbank guidelines list four groups of German-resident institutions: credit institutions under EU law, e-money institutions, payment institutions and other payment service providers. Promotional banks sit outside the population, with a consequence that is easy to miss: a transaction with a promotional bank counts as a transaction with a non-PSP and has to be reported.
Residence decides the filer. Subsidiaries of foreign parents and German branches of institutions headquartered abroad report, and the guidelines prohibit cross-border consolidation: a transaction initiated or processed through a German branch is reported in Germany and may not be reported by the foreign parent. A domestic parent may apply to file a group report (Konzernmeldung) only where its subsidiaries share its reporter type, are majority-owned and controlled by it, are seated in Germany, have their payments processed by it and cannot be separated from its payment flows without disproportionate effort.
One population question stays open. The 2021 instruments define the population by the residence of the provider or its branch, and the Bundesbank material reviewed for this guide does not address an EEA provider serving German customers under the freedom to provide services without a branch. That question belongs with the Bundesbank’s payments statistics team.
Two filtering rules shape the content. Transactions between two PSPs are left out when a PSP initiated them; once a non-PSP stands at the start or end of the chain, the transaction is in, and each PSP reports what it initiated even when the payment runs over an account at a third PSP. To identify PSPs inside the EU, the Bundesbank points to the ECB’s list of payments statistics relevant institutions (PSRIs). For customers outside the EU, its 2023 FAQ relies on the reporting agent’s own information about the customer.
The guidelines describe the statistic as a full census, and an institution with nothing to report in a period files a nil return (Fehlanzeige) for it. The derogation route that the ECB regulation offers smaller providers is closed in Germany, as the caveats section explains.
What the ZVS9 report contains: 13 positions, sent side only
The schema has 13 position codes. Each cell carries a number of transactions and a value, split into a total column and one column per country of the world. Everything sits on the sent side, labelled “gesendet (to:)”; the corresponding received transactions are reported half-yearly in the ZVS 4.1 and ZVS 4.2 schemas. Figures are totals for the reporting period.
| Position | What it captures | Reported by |
|---|---|---|
| PCT | Credit transfers (Article 4(24) PSD2), SEPA and non-SEPA | Initiating institution; for transfers initiated through a payment initiation service, the account-servicing institution |
| PCT.2 | Of which initiated electronically; PCT.2.R plus PCT.2.NR | As PCT |
| PCT.2.R | Remote: online banking, banking app, mobile payment solutions | As PCT |
| PCT.2.NR | Non-remote: credit transfer terminal, POS terminal | Initiating institution |
| PDD | Direct debits, one-off and recurring; each collection in a recurring series counts as one transaction | Payee’s PSP that submits the debit, or the first PSP in the chain |
| PCP | Card-based payments with cards issued by German-resident PSPs, excluding e-money-only cards | Card issuer |
| PCP.2 | Of which initiated electronically; PCP.2.R plus PCP.2.NR | Card issuer |
| PCP.2.R | Remote card payments, such as internet purchases | Card issuer |
| PCP.2.R.MCC | PCP.2.R per merchant category code, where known | Card issuer |
| PCP.2.NR | Card payments at a POS, including contactless and wallet payments | Card issuer |
| PCP.2.NR.MCC | PCP.2.NR per merchant category code, where known | Card issuer |
| PEM | E-money payments with e-money issued by German-resident PSPs | PSP of the payer or payee that initiated the payment |
| PCH | Cheques under the Scheckgesetz, including bank cheques | Account-servicing institution of the beneficiary |
For pull payments the word “sent” inverts. Under the ZVS 4 general rules that the ZVS9 chapter imports, a direct debit or a cheque is sent by the payee’s side while the money flows towards it, so the payee’s PSP reports PDD and PCH. Card payments are also triggered by the payee, yet the guidelines treat them as payer-initiated and assign them to the card issuer. A build that starts from debits to customers’ accounts will misplace incoming direct debits and miss the ones its merchant customers collect.
Where the instructions draw the boundaries
The counterexamples in the guidelines settle most classification questions:
- Card-induced direct debits (EuroELV) belong in PDD; the guidelines list them as a counterexample for electronically initiated card payments.
- Mail and telephone orders paid by card, imprinter slips and paper vouchers used in place of a card belong in PCP and stay out of PCP.2.
- E-money spent with a card goes to PEM, while a credit transfer or direct debit that leaves an e-money account and arrives as scriptural money goes to PCT or PDD.
- QR-code-based credit transfers are listed as a counterexample for non-remote initiation.
- ATM cash withdrawals and deposits, credit transfers at ATMs and cashback where the customer authenticated with the card fall outside PCP. Card credits are reported only half-yearly, under “other payment services” in ZVS 4.1.
Merchant category codes
The two MCC rows apply only to electronically initiated card payments. The MCC is the four-digit code from ISO 18245, and the guidelines require a separate line for each MCC the reporting agent knows; a transaction without a known code stays in PCP.2.R or PCP.2.NR with no MCC line, which is why the sum checks treat the MCC rows as “at least” relationships. Annex 2 to the schemas holds the valid list. Codes 3000 to 3350 collapse into G300 (airlines), 3351 to 3500 into G335 (car rentals) and 3501 to 3999 into G350 (hotels), and a code not yet listed goes under the placeholder R999. The 2023 FAQ confirms that the list mirrors the one Visa and Mastercard use, including codes only one of them uses, with the three groupings as the only deviation.
Annex 2 also lists 6010 and 6011, the financial-institution cash disbursement codes, while the guidelines name cash withdrawals as a counterexample for PCP.2.NR.MCC, so a withdrawal coded 6011 stays out of the card payment rows. The 2023 FAQ (question 59) adds that only transactions other than card-based cash disbursements are reported under those two codes, and where an institution cannot separate them, the codes stay out of the card payments in the quarterly report. The guidelines say Annex 2 is refreshed every six months. The version on the Bundesbank’s service page is dated 5 August 2025, with an MCC sheet status date of 1 April 2025, so a code table frozen in 2022 needs comparing against the current file.
Geo6: one column per country
Every position is broken down by Geo6, a column for each country of the world, using the list in Annex 1 to the schemas (Annex 1.2 covers the countries outside the EEA). The ECB table bases Geo6 on ISO 3166, and the Bundesbank list folds certain territories into their countries: France includes Monaco and the French overseas departments and collectivities named in the annex, and the United States includes Puerto Rico. The guidelines say Annex 1 is updated once a year; the file on the service page is dated 25 January 2022.
For card payments the ZVS9 chapter is explicit: the terminal location or the country of the point of sale decides. The ECB table specifies the point of sale for remote card payments and the physical terminal for non-remote ones. Under the definition the guidelines take from Regulation (EU) 2015/751, the point of sale for e-commerce is the merchant’s fixed establishment, whatever the location of the website or server. The cross-border rule for the other instruments is covered in the caveats section.
Units, currency and timing
Values are reported in full euros with two decimal places and counts as whole numbers; negative values are not allowed. Foreign-currency transactions are converted at the ESCB euro reference rate of each transaction day, or at observable mid-rates where no reference rate exists, and then summed over the period. A transaction belongs to the quarter of its execution date. The ECB’s Table 9 itself is expressed in millions, but Annex IV of the regulation leaves the rounding policy for transmission to the national central bank, and the Bundesbank’s policy is the two-decimal rule. Any mapping inherited from the pre-2022 regime should be tested against the current requirement to report transaction values in euros with two decimal places and transaction counts as whole numbers.
Returns of credit transfers, direct debits and cheques made by or for customers are not reported, and reversal postings should leave only the correct booking in the statistic. A fee netted into the payment amount changes the value without adding a transaction; a fee booked separately counts as a transaction in its own right, in both number and value.
ZVS9 deadlines and reference dates: one month after each quarter
The deadline comes from item 4 of order 8001/2021 and item 3 of determination 8002/2021, restated in section III.2 of the guidelines: the ZVS9 report reaches the Bundesbank by close of business on the last working day of the month following the reporting reference date. With calendar quarters as reference periods, Q1 is due by the last working day of April, Q2 of July, Q3 of October and Q4 of January. The semi-annual schemas ZVS1 to ZVS6 follow a slower clock, the last working day of the third month after the half-year, so end-September for the first half and end-March for the second. The Bundesbank’s published calendar shows how the two cycles interleave:
| Reporting period | Schemas | Latest submission date |
|---|---|---|
| Q4 2025 | ZVS9 | 30 January 2026 |
| H2 2025 | ZVS1 to ZVS6 | 31 March 2026 |
| Q1 2026 | ZVS9 | 30 April 2026 |
| Q2 2026 | ZVS9 | 31 July 2026 |
| H1 2026 | ZVS1 to ZVS6 | 30 September 2026 |
| Q3 2026 | ZVS9 | 30 October 2026 |
| Q4 2026 | ZVS9 | 29 January 2027 |
When a month ends on a weekend, the published dates fall on the preceding Friday: 31 October 2026 is a Saturday and the Q3 2026 date is 30 October, and 31 January 2027 is a Sunday and the Q4 2026 date is 29 January. The published list stays the authority for each period. The Bundesbank’s FAQ on the revised statistic also rules out deadline extensions for implementation difficulties, because the amended ECB regulation does not provide for them.
The first reference period was the first quarter of 2022. Item 2 of both instruments made the quarter beginning on 1 January 2022 the first reporting period, and the FAQ set the first quarterly due date at 29 April 2022, with the first half-yearly report due on 30 September 2022. Article 8a of the amended regulation required the Bundesbank to send the Q1 2022 data to the ECB by end-May 2022.
Submission of ZVS9 through NExt: XML files, RIAD codes and file names
All ZVS data deliveries, including the standardised nil return, are submitted in XML. The 2021 instruments named the Bundesbank ExtraNet as the channel; the switch to NExt runs through section III.3 of the guidelines (version of 1 July 2026) and the Bundesbank’s migration FAQ (version 1.5 of 22 September 2026). From 1 July 2026 every ZVS submission goes through NExt, whether quarterly or half-yearly, first submission or correction, current period or earlier one. There was no parallel run: ExtraNet stopped accepting ZVS files at the start of the production switchover window, 26 to 30 June 2026, and the FAQ confirms that NExt file upload is the only permitted route.
NExt changed the file name and left the content and structure of the XML file as they were. The ZVS XML schema package for submissions from 1 July 2026 is listed under “Verfahren: Zahlungsverkehrsstatistik” on the Bundesbank’s XML formats page (a ZIP dated 23 March 2026), and the separate Excel-based tool for generating XML files carries the same date on the payments-statistics service page. The FAQ prescribes seven mandatory name elements:
| Element | Value |
|---|---|
| Subject prefix | ZVS |
| Process mode | P for production, T for test |
| Report type | Q for quarterly, H for half-yearly |
| Identifier | RIAD code of the reporting agent, seven alphanumeric characters |
| Reporting period | Last day of the period, as YYYYMMDD |
| Message-ID | The agent’s own identifier, alphanumeric plus underscore, usable only once |
| Extension | .xml, or .zip for a zipped XML file |
The FAQ’s quarterly example is ZVS.P.Q.DE12345.20260930.Ihre_ID.xml. The report-type letter carries real weight, because 30 June and 31 December are the reference dates of both a quarterly and a half-yearly report and the letter is the only element that separates the two files. The identifier, in the file and in its name, must now be the RIAD code: ExtraNet accepted the bank sort code (Bankleitzahl) or the RIAD code, NExt accepts RIAD only, and the FAQ points to the ECB’s published PSRI list for anyone who needs to look the code up. An underscore in the Message-ID is allowed, but the Bundesbank’s Excel tool for generating NExt XML files (version of 23 March 2026) cannot produce one.
Access sits with the reporting institution. Each needs at least one User Manager for the “Finanzielle Statistiken” work area, appointed on a form signed by two authorised signatories, who authorises users for the ZVS subject areas covering submissions, where the FAQ asks for at least two users to cover absences, and communication. Test files use T as the process mode and a separate registration on the NExt test environment, which stayed open after the production switch.
Where a data centre or IT service provider files on the institution’s behalf, the technical checks reject a file from an unknown submitter (code DN0061_DE) unless an attribution declaration naming the authorised submitter reached the Bundesbank beforehand. Feedback files, technical and then content, each as XML and PDF, plus reminders, keep their substance and take NExt-convention names. Under section III.4 of the guidelines, keeping the submitted reports of the current and previous calendar year is sufficient, provided the institution can still produce correction or replacement reports for every reference date in that window.
Validation of ZVS9: technical rejections, sum checks and the half-year test
NExt runs only the intake checks; technical and content validation still happen in the Bundesbank’s ZVS reporting system, which acknowledges a formally correct file with AK0001, correct content with AK0002 (provisional acceptance) and a file that passes every plausibility check with AK0003. The rejection codes most relevant to a quarterly file, with the Bundesbank’s stated trigger:
| Code | Trigger |
|---|---|
| FL0046_DE | File name does not follow the technical specification |
| FL0041_DE | Message-ID already used in a file received earlier |
| FL0050_DE | A file with a later creation timestamp already exists for the period |
| FL0051_DE | CHANGE file sent before a FULL_REPLACEMENT file for the period was processed |
| DN1020-[Cube_ID] | Periodicity of the file does not match the schemas it contains |
| DN1013 | Report contains only zeros; a nil return is required instead |
| DN1011 | Nil-return file contains reporting positions |
| NV-[Cube_ID] | A position has a number without a value, or a value without a number |
| UQ-[Cube_ID] | The same key combination appears twice |
| DN0070_DE2 | Reference date invalid or in the future, nil returns included |
| FL0998_DE | Test flag does not match the environment |
The submission type travels inside the file. SBMSSN_TYP takes FULL_REPLACEMENT, CHANGE or NO_REPORT, the last being the nil return, and a CHANGE file is accepted only once a FULL_REPLACEMENT for the same period has been processed.
Arithmetic checks inside the quarter
The Bundesbank’s list of sum checks, dated 1 January 2026, carries six ZVS9 rules plus a country rule, all of which can be replicated in the build before upload:
- S903: PCT.2 equals PCT.2.R plus PCT.2.NR.
- S904: PCP.2 equals PCP.2.NR plus PCP.2.R.
- S905 and S906: PCT is at least PCT.2, and PCP is at least PCP.2.
- S901 and S902: PCP.2.NR is at least the sum of its MCC lines, and so is PCP.2.R.
- The LS rule for ZVS 3 to ZVS9: the country columns add up to the W0 total.
The cross-frequency test
The logical checks, dated 25 February 2025, compare the semi-annual ZVS 4.1 and ZVS 4.2 figures with the two ZVS9 quarters of the same half-year. Rules L4191 to L4196 cover credit transfers in total, remote and non-remote credit transfers, direct debits, e-money payments and cheques; L4291 to L4293 cover card payments in total, remote and non-remote. Point 9 of the ZVS9 chapter states the rule in prose: for every position also in ZVS 4, Q1 plus Q2 equals the first half-year and Q3 plus Q4 the second. Annex IV of the ECB regulation makes consistency across frequencies part of the accuracy standard for reporting agents.
Because the half-year report arrives two months after the Q2 file, a quarterly classification error can stay invisible until the ZVS 4 report is validated, and the break then takes a correction report for whichever reference date carries the error.
Plausibility queries after the NExt switch
Content queries from the Bundesbank’s data-quality process now arrive as Excel files through the ZVS communication subject area. The reporting agent completes the file and returns it through “Einreichungen und Status”; where the review finds reporting errors, the agent submits a correction report for the reference date concerned and either confirms the correction or states the date by which it will follow. Version 1.5 of the FAQ adds that query files, which it expected to apply from early October 2026, are named ZVSK, P, report type, RIAD code, a date and a Message-ID, with the extension .xlsx, and must go back under the same file name. Their date element may fall on a day that is not a quarter-end or year-end. Where no valid submission exists for a period, reminder code EC0010 asks for one within the next two weeks.
Caveats and interactions: no derogations, ZVS 4 overlap and BaFin data sharing
Proportionality in the ECB regulation runs through Article 4. Under Article 4(2) to (4), national central banks may grant derogations to qualifying payment institutions, e-money institutions and certain other payment service providers. For the transaction-value test, the total contributed by all potentially eligible providers must not exceed 5% nationally for each listed payment service and 5% cumulatively across those services. Alternatively, for account information services, their combined client count must not exceed 5% nationally. In either case, derogations are permitted only where the reporting burden would be disproportionate to the size of the reporting agents.
A derogated agent reports Tables 4b and 5b annually in place of Tables 4a and 5a, and Annex III exempts it from Table 9.
Germany has not taken up that discretion. The statement of reasons in both 2021 instruments says no Article 4 derogations can be granted, because a derogation leads to annual reporting while the collection BaFin runs under section 54(5) of the Payment Services Supervision Act (ZAG), which the Bundesbank data replace, requires semi-annual delivery among other things. The 2023 FAQ gives the same answer and names the aim: a single data flow for fraud data.
Item 6 of order 8001/2021 and item 5 of determination 8002/2021 pass data collected under the regulation to BaFin to the extent needed to replace that section 54(5) collection, under a cooperation agreement that keeps the confidentiality limits of Council Regulation (EC) No 2533/98. The statement of reasons ties the sharing to fraud data, which sit in the semi-annual ZVS5 schemas; ZVS9 carries no fraud positions. Fraud reporting under Article 96(6) PSD2 and EBA/GL/2018/05 is covered in our PSD2 reporting requirements guide for payment institutions.
ZVS9 and the semi-annual ZVS 4 share their definitions. The ZVS9 chapter imports the ZVS 4 general rules on reportable transactions, reporting agents, outsourcing, cross-border classification, direction of flows, returns and fees, plus the definitions of card issuer, acquirer and remote initiation (points 2 to 8 and 10 to 12). The schemas still differ in ways that change the build:
| Feature | ZVS9 | ZVS 4.1 and ZVS 4.2 |
|---|---|---|
| Frequency | Quarterly | Half-yearly |
| Direction | Sent only | Sent and received |
| Geography | Geo6, every country of the world | Geo3, every EEA country plus rest of world; Geo3 by Geo3 for card payments in ZVS 4.2 |
| Extra breakdowns | MCC for electronic card payments | Payment schemes, strong customer authentication and exemption reasons, initiation sub-channels |
| Due | Last working day of the month after the quarter | Last working day of the third month after the half-year |
The ZVS9 chapter leaves out point 9 of the ZVS 4 general part, the Geo3 rule, and sets Geo6 in its place. For instruments other than cards, the imported cross-border rule looks only at the countries of the PSPs at the start and end of the transaction; the customers’ nationality and residence are irrelevant, and so is the route the payment takes between PSPs. The guidelines spell the column logic out only for card payments; for a credit transfer, the imported rule points to the country of the receiving PSP, which is an inference from that rule rather than explicit ZVS9 text.
Order 8001/2021 also adds, for credit institutions, national items collected under section 18 of the Bundesbank Act (BBankG): card-induced direct debits (EuroELV) and mobile card payments at the POS. They sit in the semi-annual schemas as memorandum items PDD.5 and PCP.2.NR.1, both reported at Geo1, and stay outside ZVS9.
Changes to ZVS9 reporting: from the 2020 amendment to NExt
| Date | Change |
|---|---|
| 27 February to 7 May 2020 | ECB public consultation on the draft amending regulation |
| 11 December 2020 | Regulation (EU) 2020/2011 published in OJ L 418 |
| 27 April 2021 | Bundesbank order 8001/2021 and determination 8002/2021 adopted; published in the Bundesanzeiger on 16 June 2021 |
| 10 August 2021 | ZVS 6 and ZVS 9 chapters added to the guidelines |
| 1 January 2022 | Amended regulation applies; Q1 2022 is the first ZVS9 reference period |
| 24 January 2022 | Guidelines clarify the reporting obligation for ZVS9 direct debits |
| 1 April 2022 | The 2014 Bundesbank instruments are revoked |
| 8 August 2022 | Cash withdrawals (MCC 6010 and 6011 where used) added as a counterexample for PCP.2.NR.MCC |
| 1 January 2023 | ZVS9 country breakdown: the point of sale decides for card payments |
| 1 January 2026 | Shared definitions updated: Wero added as an example in the ZVS 4.1 online and mobile credit transfer positions, e-money without direct storage reported as e-money account transactions, mail and telephone order card payments classified as not electronically initiated; current sum-check list dated 1 January 2026 |
| 1 July 2026 | NExt replaces ExtraNet for all ZVS submissions; guidelines version removes giropay and paydirekt from the ZVS 4.1 examples |
| 22 September 2026 | Migration FAQ version 1.5 adds query-file handling, which it expected to apply from early October 2026 |
Changes made to ZVS 4 positions reach ZVS9 because the schemas share definitions and the half-year test ties their totals together. On the EU side, the documents reviewed for this guide announce no further amendment to Regulation (EU) No 1409/2013, so the reference data in Annex 1 and Annex 2 change more often than the rules. One point remains open. The 2023 FAQ, answering how to report an MCC missing from the list, said revisions would be made above a size still to be defined, and the current guidelines name no such threshold.
Frequently Asked Questions
We outsourced payment processing to another bank. Who reports our customers’ transactions in ZVS9?
The outsourcing institution. The ZVS 4 general rules imported into ZVS9 say that institutions which have outsourced their payments, or process them through an account at another PSP, remain the reporting agent for the transactions they initiate and receive, because they hold the direct customer relationship. The PSP that executes the transfer or first collects the debit does not report those transactions in their place.
How are standing orders counted when they run as a daily institution file?
The 2023 FAQ treats them as consecutive single credit transfers where the customer gave the order individually, outside a bulk transfer. For standing orders newly set up by customers from 1 January 2022, the initiation channel has to be recorded; for older ones, the previous classification may be kept, or a classification based on the business model fixed and applied in all later reports.
Are credit transfers sent over EBICS remote or non-remote?
The 2023 FAQ says payments initiated over EBICS are generally recorded as bulk credit transfers via remote access, which places them in PCT.2.R. An EBICS file holding a single transaction is reported as a single online credit transfer in the semi-annual breakdown.
A merger takes effect during a half-year, before its half-year report is due. Who files what?
Under section III.5 of the guidelines, from the legal merger the absorbing institution files a cumulative report for the whole reporting period, also where the merger takes effect after the period ends but before its deadline. The Bundesbank’s FAQ on the revised payments statistics (10 February 2023, question 61) then distinguishes by timing for the first half-year: for a merger in January to April, the transferring institution reports nothing and the absorbing institution reports Q1, Q2 and H1 cumulated; for May to July, the transferring institution files Q1 and the absorbing institution files Q2 and the cumulative H1 return; for August or September, the transferring institution files both Q1 and Q2 and the absorbing institution files the cumulative H1 return. Section III.5 of the guidelines states the same principle for the first and third quarters, so the equivalent timing applies in the second half-year. Where a merger causes a reconciliation query between the quarterly and half-yearly validation rules, the FAQ provides for a one-off exception to be requested by e-mail to the Bundesbank.
Do payments in a correspondent banking relationship belong in ZVS9?
Payments arising from interbank trading are not recorded in the statistic. Where a domestic PSP initiates a transaction through a correspondent banking relationship, the initiating PSP reports it, and the 2023 FAQ states that the correspondent bank must not report the same transaction. Where the initiating bank is a promotional bank, the same FAQ answer requires the correspondent bank to report the transaction, because promotional banks are not reporting PSPs under the amended ECB regulation.
Are payments under documentary credits reportable?
Yes. The 2023 FAQ says payments from documentary business, such as import and export letters of credit, are reportable and recorded according to the payment actually made with the non-PSP.
Related Articles
- AnaCredit Reporting in Germany: Bundesbank Credit Data and Deadlines: loan-level credit reporting to the Bundesbank, also filed as XML through NExt.
- PSD2 Reporting Requirements for Payment Institutions: Complete Practitioner Guide: the separate PSD2 reporting streams, fraud data included, for payment and e-money institutions.
- Riksbank Payment Statistics Reporting: The 1 October 2026 Go-Live: Sweden’s national payment statistics regime under RBFS 2025:1.
- Bundesbank Payment Behaviour in Germany 2025: What the Survey Findings Mean for PSP Compliance and Reporting: the Bundesbank’s consumer survey and how it relates to the statistics PSPs file.
- Bundesbank Customer Classification in 2026: RS-57 sFEU Update and NACE Rev. 2.1: counterparty classification for German statistical returns.
Key Takeaways
- Map the sent side per instrument before writing any account logic: payee’s PSP for direct debits and cheques, card issuer for card payments, initiating institution for credit transfers.
- Book EuroELV card-induced debits under PDD, and keep QR-code credit transfers out of PCT.2.NR.
- Run S901 to S906 and the country-total rule against every quarterly file before upload.
- Reload Annex 2 (MCC codes) and Annex 1 (countries) whenever the Bundesbank publishes a new version, and route unlisted MCCs to R999.
- Return each Bundesbank query file under its original name, with a correction report or a committed correction date.
- Keep the submitted ZVS files of the current and previous calendar year, and the ability to regenerate any reference date in that window.
- Put the services-only case, an EEA provider serving German customers without a branch, to the Bundesbank before assuming it is out of scope.
Sources and References
- Regulation (EU) No 1409/2013 of the ECB of 28 November 2013 on payments statistics (ECB/2013/43), OJ L 352, 24.12.2013: EUR-Lex
- Regulation (EU) 2020/2011 of the ECB of 1 December 2020 amending Regulation (EU) No 1409/2013 (ECB/2020/59), OJ L 418, 11.12.2020: EUR-Lex
- Guideline (EU) 2021/832 of the ECB of 26 March 2021 on reporting requirements on payments statistics (ECB/2021/13), OJ L 208, 11.6.2021: EUR-Lex
- Deutsche Bundesbank, Mitteilung Nr. 8001/2021 of 27 April 2021 (credit institutions): PDF
- Deutsche Bundesbank, Mitteilung Nr. 8002/2021 of 27 April 2021 (payment service providers that are not credit institutions): PDF
- Deutsche Bundesbank, Zahlungsverkehrsstatistik service page: bundesbank.de
- Deutsche Bundesbank, payments statistics reporting page (English): bundesbank.de
- Deutsche Bundesbank, general guidelines on the revised payments statistics, version of 1 July 2026: PDF
- Deutsche Bundesbank, FAQs on the move of the ZVS from ExtraNet to NExt, version 1.5 of 22 September 2026: PDF
- Deutsche Bundesbank, FAQ on the revised payments statistics, 10 February 2023: PDF
- Deutsche Bundesbank, list of technical checks: XLSX
- Deutsche Bundesbank, quality and plausibility checks, sums (1 January 2026): XLSX
- Deutsche Bundesbank, quality and plausibility checks, logical (25 February 2025): XLSX
- Deutsche Bundesbank, Annex 1, geographical breakdowns (25 January 2022): XLSX
- Deutsche Bundesbank, Annex 2, payment systems and MCC list (5 August 2025): XLSX
- Deutsche Bundesbank, XML formats for banking statistics, including the ZVS schema for submissions from 1 July 2026: bundesbank.de
- Deutsche Bundesbank, unofficial translation of the ECB FAQ on the payments statistics regulation: PDF
- European Central Bank, public consultation on the draft amending regulation on payments statistics: ecb.europa.eu
- Directive (EU) 2015/2366 (PSD2): EUR-Lex
- Directive 2009/110/EC on electronic money institutions: EUR-Lex
- Regulation (EU) 2015/751 on interchange fees for card-based payment transactions: EUR-Lex
- Council Regulation (EC) No 2533/98 on the collection of statistical information by the ECB: EUR-Lex
Before the next ZVS9 quarter-end
A ZVS9 build has a natural order: the population first, since no derogation will shrink it, then the sent-side mapping, the reference tables and the checks the Bundesbank will run anyway. Each cycle ends in the same artifact, one XML file per quarter uploaded to NExt under a name that starts ZVS.P.Q and carries the institution’s RIAD code and the quarter’s last day. Each quarter’s file is due at the Bundesbank by close of business on the last working day of the following month.
Disclaimer: The information on RegReportingDesk.com is for educational and informational purposes only. It does not constitute legal, regulatory, tax, or compliance advice. Always consult your compliance officer, legal counsel, or the relevant supervisory authority for guidance specific to your institution.
