BZSt FATCA DIP Filing: Handbook v1.5 and the XML Upload Route

Version 1.5 of the Kommunikationshandbuch FATCA Teil 1, dated 3 August 2026, is the Bundeszentralamt für Steuern (BZSt) manual that governs BZSt FATCA DIP transmission for German reporting financial institutions and the service providers that file on their behalf. The change history lists a single addition: information on encoding for files sent through the XML upload in the BZSt online.portal. Those files are to be plain UTF-8, and the handbook names UTF-8 with a byte-order mark (BOM) as an example of what can trigger a technical rejection for schema invalidity.

One paragraph would hardly justify a closer look, except that version 1.5 is the fifth revision of a handbook first issued in February 2026, after the BZSt replaced its old ELMA mass-data interface with DIP (Digitaler POSteingang). The switch removed the separate receipt that ELMA used to send, added a second mass-data route through the portal in July 2026, and moved processing feedback into DIP protocols, DIP user messages and, for uploads, the portal. Section 8(3) of the FATCA-USA-Umsetzungsverordnung (FATCA-USA-UmsV) prescribes 31 July of the following calendar year as the annual filing date. Because 31 July 2027 falls on a Saturday, its interaction with § 108 AO must be assessed before the final legally permissible filing date is stated. For now this document is the BZSt’s technical reference for every route those reports can take.

Related reading: BZSt CRS Reporting: The Schema v3.0 Switch and Saint-Martin Refile

The dates behind the DIP switch and version 1.5

The handbook only makes sense against the BZSt’s own rollout calendar, which is spread across its FATCA newsletters. The operative dates are below.

The December 2026 item is the one the BZSt itself flags as possibly requiring changes on the customer side, since a new protocol schema reaches whatever software parses the BZSt’s responses.

Five revisions in six months, and what version 1.5 adds

Every version of the DIP handbook so far is tied to FATCA XML schema 2.0.1. The revisions track the rollout rather than any change in what has to be reported.

Version 1.5 leaves the FATCA XML schema untouched. The handbook (section 3) states that the FATCA XML schema version was updated from 2.0 to 2.0.1 on 29 September 2025, that the update adjusted country and currency lists on the FATCA system side only, and that data senders did not need to change their systems. The IRS schema page lists the v2.0.1 package as updated on 6 October 2025; the 29 September date is the handbook’s own statement and the IRS date is that of the published package. A handbook revision does not itself establish that the FATCA XML schema has changed, so implementation decisions should rest on the schema and validation specifications currently applicable.

The BZSt explained the reason for the new paragraph in FATCA Newsletter 07/2026: many upload submissions were being rejected for schema invalidity because of incorrect encoding, and some had been sent as UTF-8 with BOM. The newsletter asks for plain UTF-8 and recommends declaring the encoding in the first line of the file, in the form of an XML declaration naming utf-8. Section 6.2 now carries the same instruction, alongside the rule that an upload must contain only the FATCA-specific XML. A file that still wraps the payload in the DIP envelope receives a technical rejection.

The DIP route applies its own encoding checks. The handbook’s error list includes E0300 for a DIP file not encoded in UTF-8, E0603 for a missing XML declaration and E0604 where the declaration names something other than UTF-8, with “UTF8” given as an invalid value. Section 5.4.5 adds that other encodings are not supported and points to the KoSIT “Lateinische Zeichen in Unicode” character set as the orientation for name and address data.

Legal basis: the regulation sets the duty, the handbook sets the mechanics

The reporting obligation rests on the agreement between Germany and the United States signed on 31 May 2013. Its assent law entered into force on 16 October 2013 (BGBl. II S. 1363), and the agreement took effect on 11 December 2013. The FATCA-USA-UmsV (BGBl. I 2014 S. 1222) was issued under the power in § 117c of the Abgabenordnung (AO). The BMF’s application letter of 1 February 2017 (BStBl. I 2017, 305), with supplementary letters of 21 September 2018 and 15 June 2022, covers interpretive questions for both CRS and FATCA.

Section 8(3) of the regulation carries the core filing rule: the reporting German financial institution transmits the data by 31 July of the following calendar year, using the officially prescribed dataset, by remote data transmission. The same paragraph allows the institution, where it does not hold the US TIN of a specified US person, to report in addition the TIN or functional equivalent of each state of residence (only where its electronically searchable account information contains it) and the date of birth. Section 8(5) makes the US TIN mandatory for data from calendar year 2017 onwards.

The handbook draws its own boundary in section 0.2. It describes itself as an explanation of, and supplement to, the official dataset description under § 117c AO and § 8(3) FATCA-USA-UmsV. That official specification is the “Datensatzbeschreibung nach FATCA-XML-Schema v2.0.1”, listed in the handbook’s reference table. A second hierarchy applies to DIP itself. Where the FATCA handbook quotes the general Kommunikationshandbuch DIP Standard, section 2.1 says the DIP Standard text prevails if the two diverge. The BZSt’s DIP page currently offers DIP Standard document version 2.4, dated May 2026 and valid from 1 June 2026.

One passage in the legal-basis section has not kept pace with the law. Section 1.1 still describes the FATCA-USA-UmsV as last amended on 20 December 2016. The consolidated text on gesetze-im-internet.de shows the regulation as last amended by Article 11 of an act of 29 June 2026 (BGBl. 2026 I Nr. 197). For the content of the obligation, the consolidated regulation is the text to read. The handbook’s value lies in the transmission rules, and section 1.4 adds a reminder that breaches of the statutory FATCA obligations can lead to administrative fine proceedings.

Three routes into the BZSt, two of them for mass data

The handbook lists three ways to deliver FATCA data. Individual reports can be entered in the FATCA forms in the BZSt online.portal; Newsletter 02/2026 describes one form for new data (DocTypeIndic FATCA1) and a separate follow-up form for FATCA2, FATCA3 and FATCA4. Mass data, meaning XML files, can go either machine-to-machine through DIP or through the XML upload in the portal. The BZSt online.portal supports several identity services, but authentication requirements depend on the filing service. Handbook section 6.2 names BundID, an ELSTER certificate or a BOP certificate for the XML upload, whereas the German federal service description for FATCA reports (service key 99102099261000, approved by the BMF on 4 August 2026) states that access runs through a certificate issued by the BZSt or by ELSTER. The published sources therefore differ on whether BundID alone is accepted, so confirm the accepted authentication for the chosen route with the BZSt before relying on it. DIP also requires registration of the data sender with the BZSt’s FATCA department and activation of the DIP interface, and section 6.1 requires a separate activation for production and for the customer test environment.

The forms route has a documentation gap of its own. The BZSt’s handbook page states that a new Part 2 for individual data in the new portal will be published as soon as possible, and that until then the legal and technical details can be taken from Part 1. For now, the BZSt therefore points to the Part 1 handbook for the legal and technical details of all three routes, although the portal’s own guidance on the individual forms supplements it, which is a different set-up from a direct IRS filer; our guide to Form 8966 reporting through IDES covers that channel, whereas a reporting Model 1 institution in Germany reports to the BZSt, which exchanges the data with the US competent authority.

Section 6.2.1 compares the two mass-data routes. The table below restates it.

Whichever route is used, one FATCA report can name only one financial institution. A service provider (Meldestelle) filing for several institutions creates a separate report per institution, and the DIP header identifies the sender through the consignment customerIdentifier, such as a tax number or BZSt number. Other Model 1 jurisdictions run their own channels; the Luxembourg set-up is covered in our FATCA reporting in Luxembourg guide.

Readers should also be aware of a stale sentence. The introduction to section 6 still says that DIP is currently the only option for mass data and that a portal upload client will be provided in future. Section 6.2 and FATCA Newsletter 06/2026, which reported the upload’s activation on 15 July 2026, show it is available now.

Inside the BZSt FATCA DIP envelope: header fields that reject files

On the DIP route, the FATCA XML sits inside a standard DIP wrapper. The root element dip works as an envelope with a header and a body; the body carries the FATCA payload, and exactly one FATCA XML may travel in each dip:body. The file is validated against the current DIP schema, and the payload at XPath dip/body/consignmentItem/data against the FATCA schema.

Two different version numbers apply, and they are easy to mix up. The DIP interface version that FATCA accepts is 2.1 (section 2.2), and user messages are available only from interface version 2.1. The version attribute on the dip root element, which the handbook calls the DIP schema version, takes the value 2.0 (section 2.3). FATCA Newsletter 05/2025 explains that the BZSt renamed the field label to “DIP Schema-Version” precisely to stop senders confusing it with the interface version.

The header fields are short, and each has its own rejection path.

For version 2 data, section 5 names the enveloped signature, integrated into the XML file, and refers to the DIP Standard handbook for the worked example. DIP rejects a file carrying both an enveloping and a detached signature (E0502). Connections run over HTTPS against a REST interface, using an access token requested at the auth endpoint with a request token signed by the private key used for the DIP activation certificate. Section 5.4.4 caps the rate at ten submissions started per minute at the “Anmelden” endpoint; above that, DIP answers with return code 429, which matters to a batch job pushing many single-institution files in a loop.

Payload rules that reject a whole delivery

Section 5.5 sets out business rules where one mistake rejects the complete delivery. A delivery may contain reports for only one reporting financial institution and only one reporting period, and ReportingPeriod takes the format YYYY-12-31. Mixing institutions or periods rejects the whole file.

The two reference identifiers look alike but follow different character rules.

A plus sign or underscore that is valid in a MessageRefId will therefore break a DocRefId built from the same routine. Section 5.5.5 also covers institutions without their own GIIN that have to use the fixed value 000000.00000.TA.276: the free part of the DocRefId then combines the sender’s BZSt number, the ten-digit BOP account ID and a running number.

FilerCategory must be filled exactly once. If a sponsor is named, the entry goes on the sponsor (values FATCA607 to FATCA609) and the ReportingFI carries none; without a sponsor, it goes on the ReportingFI (FATCA601 to FATCA606, FATCA610 or FATCA611). Omitting it or using it twice rejects the delivery. The PoolReport group must not appear at all, and the handbook stresses that even an empty PoolReport element causes full rejection. Optional groups that are not needed should be left out, and a sponsor without a TIN must not carry an empty TIN element, because an empty TIN fails schema validation.

Character rules come from the IRS requirements as the handbook applies them. Table 3 in section 5.4.7 lists the ampersand, less-than and greater-than signs, the apostrophe and the quotation mark as characters to be replaced by their XML entity equivalents, and states that using them unreplaced leads to rejection of the complete delivery. A double hyphen, a slash followed by an asterisk, and an ampersand followed by a hash sign are banned outright with no substitute. An apostrophe or other special character immediately followed by certain letter combinations, with SQL keywords such as AND, AS, IN, MIN, OR or SUM given as examples regardless of case, can also reject the whole delivery, and the handbook’s own fix is to drop the special character, so that D’Andressa becomes DAndressa.

File size is the one point where the handbook contradicts itself. Section 5.4.2 says the XML file should be smaller than 100 MB and that exceeding this maximum leads to rejection, while the comparison table in section 6.2.1 gives 1 GB for DIP and 200 MB for the upload. A DIP file under 100 MB would satisfy both statements. Anyone planning to rely on the higher figure has good reason to confirm it with the FATCA department first.

US TIN codes for reporting periods 2025 to 2027

The longest part of the handbook deals with the TIN of account holders and controlling persons. For validation of the FATCA TIN element, the handbook (sections 5.5.6.2 and 5.5.6.3) lists four accepted patterns, which the IRS treats as GIIN-formatted identifiers plus three nine-digit US taxpayer identification number formats: XXX-XX-XXXX, XX-XXXXXXX and XXXXXXXXX. The 19-character GIIN pattern (XXXXXX.XXXXX.XX.XXX) identifies FATCA-registered entities and must not be treated as a fourth US taxpayer-number format for an account holder or controlling person. A foreign TIN follows no fixed format and is submitted in a TIN element with the issuing country in the issuedBy attribute.

IRS Notice 2024-78 extends the temporary relief of Notice 2023-11 to the 2025, 2026 and 2027 calendar years for preexisting accounts at reporting Model 1 institutions in eligible Model 1 IGA jurisdictions. Section 5.5.6.3.5 of the handbook confirms that the alternative codes were not updated, so the 2022 to 2024 code set still applies.

The former fallback AAAAAAAAA is no longer accepted from reporting period 2024 and leads to rejection of the affected records.

A code does not discharge the duty to obtain the TIN, and the handbook states that the IRS is still expected to return an error even where a code is used. From that error notice, the institution has 120 days to correct it, after which the IRS reserves the right to evaluate the data and, in a given case, determine significant non-compliance. The handbook lists six cumulative conditions the BZSt reads into Notice 2024-78: the date of birth of each natural-person account holder or controlling person without a reportable US TIN; an annual request for each missing required US TIN, using a communication method reasonably likely to reach the account holder and including either the State Department Joint FATCA FAQs web address or a copy of those FAQs together with the IRS former-citizen relief procedures or their web address; an annual search of electronically searchable account data for missing required US TINs, which the handbook places before transmission of the reports; a specific alternative code per account; the foreign TIN or comparable information where the electronically searchable data contains it; and mandatory use of the AddressFix group with city and country of residence. Records of these steps are to be kept until the end of calendar year 2031, which also covers the Notice 2023-11 records for 2022 to 2024. The relief depends on Germany being classified as an eligible Model 1 IGA jurisdiction under section 3.04 of the Notice.

The relief from a significant-non-compliance determination solely for a missing US TIN applies only to preexisting accounts. However, an institution seeking that relief must meet the requirements in section 3.02 of IRS Notice 2024-78 for every US reportable account with a missing required US TIN, including new accounts, and those requirements include reporting an accurate TIN code. Using a code for a new account does not make that account eligible for the relief. The handbook separately encourages using the codes for new accounts where no US TIN can be given. Other revenue authorities have issued their own TIN guidance; our article on FATCA reporting in Ireland and Revenue’s US TIN update shows a parallel approach.

Correcting a filed report: FATCA2, FATCA3 and FATCA4 in sequence

Each FATCA report may carry only one DocTypeIndic. A delivery that sends one account as new data and corrects or deletes another in the same file is rejected. The four values divide the work as follows:

• FATCA1 (New Data) covers records never sent, records the BZSt’s checks rejected, and records previously deleted with FATCA3 that are being sent again.
• FATCA2 (Corrected Data) is reserved for the case where a US receipt (UEFI) points to an error in a record and asks for a corrected record.
• FATCA3 (Void Data) deletes records that were sent in error or that contain errors to be cleared by cancelling the original.
• FATCA4 (Amended Data) changes records the IRS has accepted, and only after a UEFI without objections.

A record the BZSt rejected has never been accepted, so it goes back as FATCA1, and FATCA2 is unavailable until a UEFI asks for it. For records with errors that need cancelling, the handbook prescribes a sequence: send the FATCA3 deletion, confirm from the processing protocol (and, where relevant, the UEFI for the deletion) that it succeeded, and only then send the cleaned records as FATCA1. Skipping the confirmation step risks duplicate records at the BZSt and the IRS. The deletion must reproduce the original record character for character; the handbook warns that one extra or missing space, or a different abbreviation of a street name, can cause a rejection.

Section 4.2.4 of the handbook states that every follow-up report refers back to the original initial report, however many follow-ups there have been, so that the report chain can be traced without gaps. The original MessageRefId goes into CorrMessageRefId, and the DocRefIds of the records being changed go into CorrDocRefId, while the follow-up itself takes a new MessageRefId and new DocRefIds. A follow-up contains only the records being changed or deleted, but each one must be sent complete; correcting only the faulty data elements is not enough.

After the status code 200: protocols, user messages and the UEFI

Under ELMA, the sender received a separate receipt (Eingangsbestätigung). Section 7.1 records that DIP dropped it, so receipt on the BZSt web server is confirmed only by HTTP status code 200. That code proves transport, nothing more. DIP then runs its technical validation: completeness of XML and signature, file sizes, UTF-8 encoding, virus checks, signature checks, DIP header schema validation, the environment check, sender identification and authorisation, duplicate and reference checks, and routing to the procedure. If any of these fail, the data never reaches the FATCA department, no business validation takes place, and the MD protocol describes the technical fault in the envelope.

Files that pass go to the FATCA back end, which produces a processing protocol (Verarbeitungsprotokoll) in XML for every file. How that protocol reaches the sender depends on the outcome, a split that replaces ELMA’s sequence of a separate receipt followed by the processing protocol.

A DIP integration therefore needs two retrieval paths. User messages require DIP interface version 2.1 and a registered DIP user, with an access token generated as for a delivery. MD protocols are polled in three steps: list all transfer numbers whose collection has not been confirmed, fetch the protocol for each number, then confirm collection. Until confirmed, a number keeps reappearing in the list, and the handbook advises against fetching protocols for numbers the list did not return. Each MD protocol stays available for three months after creation, and the technical contact receives an email when a protocol or user message is ready.

The protocol’s processStatus takes three values. OK means every report was processed without error or note entries. PARTIALLY REJECTED means at least one report carries an error or a note, or the delivery carries a delivery-level note. ERROR covers full rejection, where every report carries an error or the delivery carries a delivery-level error, and section 7.6 also places under ERROR the case where all reports carry a note and at least one carries an error, in which only the erroneous reports are rejected. The summary entry I_RESU_001 shows how many reports were processed, rejected and flagged as inconclusive. Table 9 writes the partial value as PARTIALLY_REJECTED with an underscore, while section 7.6 omits it, so a parser matching the exact string deserves a test against a real protocol.

FATCA Newsletter 08/2026, dated 12 October 2026, reports partial problems with protocol delivery and asks senders who have not received their processing protocol within one week of sending to email fatca@bzst.bund.de with an identifier such as the Vorgangsnummer or Datentransfernummer. It also notes that the portal status of a delivery currently stays at “In Bearbeitung” even after the protocol arrives, and becomes final only once the UEFI is received.

Testing on the customer test environment

The handbook points to a separate “Kommunikationshandbuch Testverfahren” for differences between test and production; the BZSt’s handbook page lists version 1.1, dated July 2026. Test files use environment value TEST and need their own DIP activation. Newsletter 02/2026 adds that the IRS cannot check test deliveries, so the test system never produces a UEFI, and the follow-up types that depend on a UEFI cannot be triggered by test-system feedback.

Newsletter 03/2026 described two constellations in DIP mass-data deliveries after which FATCA could not generate any response at all: deliveries containing several consignment items or several FATCA deliveries in one transmission, and BirthDate fields filled in the wrong format. At the time, the BZSt had no permanent fix and asked senders to avoid both. The same newsletter announced a move to a new customer test environment, expected in early June 2026, with new system URLs to be published on the DIP homepage and no other change required from users.

Frequently Asked Questions

Our initial report for an earlier period went in through ELMA. Can the correction go through DIP or a portal form?

Section 4.2 allows a follow-up through a different channel from the initial report, and gives an ELMA or DIP initial report followed by a form correction as its example. The BZSt advises against mixing channels to reduce errors. Where it happens, the handbook expects the sender to hold the full content of the original report, its processing protocol and the UEFI, and it singles out cases where a third-party IT provider sent the initial report. Newsletter 05/2025 said the old ELMA and BOP feedback channels would stay open only until June 2026.

Our fiscal year does not end on 31 December. What goes into ReportingPeriod?

ReportingPeriod keeps the YYYY-12-31 format. Section 5.5.3 asks for an additional note in the Warning element, with the text “End of non-calendar fiscal year, as value for another appropriate reporting period: YYYY-MM-DD”.

The institution’s GIIN changed after the initial report. Which GIIN goes into a correction?

Sections 5.5.4 and 5.5.5 require follow-up reports to use only the current GIIN when building the new MessageRefId and DocRefIds. The CorrMessageRefId and CorrDocRefId elements still point to the identifiers of the original report.

Is a nil report mandatory, and what if one was filed in error?

Section 5.5.8 makes the NilReport optional. A nil report that turns out to be wrong has to be deleted with a FATCA3 report, and the reportable accounts follow as FATCA1 once the processing protocol confirms the deletion. Newsletter 08/2026 adds that some nil reports submitted through the portal form were not processed; institutions that still want to inform the FATCA department and the IRS are asked to submit them again, and affected institutions were notified individually.

A customer moved all funds into a different product at the same bank. Is the old account reported as closed?

No. Under section 5.5.9, AccountClosed marks an account closed during the year or transferred in full to another financial institution. A transfer between accounts or account types at the same institution is not reported as a closure.

An account holder’s US TIN genuinely has eight digits and fails the format check. What can be entered?

Where the holder demonstrably has no TIN in a permitted format, section 5.5.6.3.6 allows the institution’s own country code in issuedBy and “NA” in the TIN element. A UEFI that already reported “TIN not in IRS specified format” for one of those reasons does not need a retroactive NA correction, but all other errors in the UEFI do. The same NA entry is available, where neither a US nor a foreign TIN exists, for a non-US entity holder such as a passive NFFE whose controlling persons are US persons and which itself has no US TIN.

Can the BZSt extend the 31 July deadline if its own systems had problems?

Newsletter 07/2026 says the deadline is statutory and the BZSt can neither extend nor suspend it. Whether a submission was timely and complete is decided by the BZSt’s AIA audit unit, which will take system inconsistencies into account in individual case reviews.

Related Articles

• BZSt CRS Reporting: The Schema v3.0 Switch and Saint-Martin Refile: the CRS side of the same BZSt infrastructure, including the move to CRS XML schema v3.0 from 1 January 2027.
• Form 8966 Reporting: FATCA Filers, IDES and the 31 March Deadline: how institutions that report directly to the IRS file through IDES.
• FATCA Reporting in Ireland: Revenue’s Paragraph 4.3 Update on US TINs: a Model 1 revenue authority’s guidance on missing US TINs.
• FATCA Reporting in Luxembourg for Financial Institutions: the Luxembourg reporting process, for groups filing in more than one IGA jurisdiction.
• CRS Reporting in Luxembourg for Financial Institutions: the parallel CRS reporting obligations for Luxembourg financial institutions.

Key Takeaways

• Before the next portal upload, strip any BOM, declare UTF-8 in the XML prolog and remove the DIP envelope; v1.5 adds the encoding rule to section 6.2.
• Choose the mass-data route according to the sender’s integration and authentication requirements. DIP requires a signed REST integration and the relevant production and test activations. Portal XML upload requires an approved filing identity; the federal FATCA service description specifies BZSt or ELSTER certificate authentication. The handbook gives a 200 MB limit for the upload; confirm the current XML/ZIP limit before submission.
• Build retrieval for both DIP channels, user messages and MD protocols, and confirm each MD protocol within its three-month window.
• If no processing protocol arrives within a week of sending, email fatca@bzst.bund.de with the Vorgangsnummer or Datentransfernummer.
• Monitor BZSt notices for the next FATCA processing-protocol schema release (the newsletters expect early to mid December 2026), and confirm the schema identifier, release date and first-use date before scheduling parser changes.
• Keep evidence of annual TIN requests and electronic searches under Notice 2024-78 until the end of 2031.
• For reporting period 2026, the statutory reference date is Saturday 31 July 2027. Confirm the effect of § 108 AO on the final legal deadline and plan operational transmission before that weekend.

Sources and References

• Bundeszentralamt für Steuern, Kommunikationshandbuch FATCA Teil 1, Datenübermittlung über die Massendatenschnittstelle DIP, Version 1.5 (3 August 2026): BZSt (PDF)
• Bundeszentralamt für Steuern, FATCA Handbücher (handbook versions, XML examples, Testverfahren v1.1): BZSt
• Bundeszentralamt für Steuern, Massendatenschnittstelle DIP (Kommunikationshandbuch DIP Standard v2.4, OpenAPI and schema versions): BZSt
• BZSt FATCA Newsletter archive: BZSt
• BZSt FATCA Newsletter 05/2025 (29 December 2025), DIP go-live: BZSt
• BZSt FATCA Newsletter 02/2026 (April 2026), reporting period 2025 and new portal forms: BZSt
• BZSt FATCA Newsletter 03/2026 (30 April 2026), Notice 2024-78, DIP error constellations, test environment: BZSt
• BZSt FATCA Newsletter 06/2026 (17 July 2026), XML upload go-live: BZSt
• BZSt FATCA Newsletter 07/2026 (August 2026), upload encoding and statutory deadline: BZSt
• BZSt FATCA Newsletter 08/2026 (12 October 2026), protocol delivery problems and portal status: BZSt
• FATCA-USA-Umsetzungsverordnung (FATCA-USA-UmsV), consolidated text: gesetze-im-internet.de
• FATCA-USA-UmsV, § 8 (data to be reported, 31 July deadline, US TIN): gesetze-im-internet.de
• Abgabenordnung § 108 (calculation of time limits, including deadlines ending on a Saturday): gesetze-im-internet.de
• Internal Revenue Service, Notice 2024-78, Extension of Temporary Relief for Foreign Financial Institutions to Report U.S. Taxpayer Identification Numbers: IRS (PDF)
• Internal Revenue Service, FATCA XML Schemas and Business Rules for Form 8966 (schema v2.0.1 package listed as updated 6 October 2025): IRS
• Internal Revenue Service, IRS FATCA Report Notifications Frequently Asked Questions, Populating the TIN Field: IRS
• Federal service catalogue (FIM), Meldungen nach dem FATCA-Abkommen, Entgegennahme, service key 99102099261000, approved by the BMF on 4 August 2026: FIM-Portal

Getting the DIP pipeline ready for the 31 July 2027 filing

Version 1.5 changes one paragraph, and for a DIP-only sender it changes nothing at all. What the revision cycle has produced is a single German manual that now governs two mass-data routes with different envelopes, signatures, size limits and feedback channels. The next technical dependency is the anticipated processing-protocol schema revision, which the BZSt newsletters expect in early to mid December 2026. Its release date, exact schema version and first-use date should be established from a current BZSt publication before changes are deployed. The practical step is to test the protocol parser against the example files the BZSt publishes under “Rückmeldungen und Protokolle” and to confirm upload encoding and protocol retrieval before the 2026 reporting period opens, ahead of the statutory 31 July reference date for the 2026 reporting period. As 31 July 2027 falls on a Saturday, how the next-working-day provision in § 108(3) AO applies should be resolved before the final permissible submission date is identified, and operational planning should target transmission before that weekend.

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.