1. Introduction
OpenFASTER is a vendor-independent family of open standards for exchanging the data required for EU withholding-tax and dividend reporting. It is designed so that Certified Financial Intermediaries (CFIs) — banks, custodians, central securities depositories, and other reporting parties — can produce and exchange this data interoperably, regardless of which vendor or in-house system they use.
1.1. Scope
The scope of OpenFASTER is purely operational: defining the technical data model, vocabulary, and (in future modules) the exchange mechanics that make indirect reporting and the collection of supplementary data efficient and standardized across the EU.
OpenFASTER deliberately does not address:
-
legislative or business-logic questions (for example, whether anonymous reporting is permissible);
-
the internal calculation of tax positions; or
-
commercial or contractual arrangements between participants.
1.2. Regulatory context
OpenFASTER is developed against the timeline of the EU [FASTER] initiative and the German [MIKADIV] reporting procedure.
| Milestone | Date |
|---|---|
| Standardized dividend reporting (MiKaDiv) | 2027-01-01 |
| Full regulatory reporting under FASTER | 2030-01-01 |
The goals shared with these initiatives are harmonized dividend reporting, reduced withholding-tax fraud, greater transparency for tax authorities, and efficient cross-border tax-reclaim processing.
2. Terminology
Certified Financial Intermediary (CFI)
- A regulated party — such as a bank, custodian, or central securities depository — that participates in withholding-tax and dividend reporting and exchanges disclosure data with other participants.
3. Versioning
Each OpenFASTER module is versioned independently using
semantic versioning (MAJOR.MINOR.PATCH):
-
MAJOR — incompatible changes to the data model (for example, removing a field, or changing its meaning or requiredness).
-
MINOR — backwards-compatible additions (for example, new optional fields or new enumeration values).
-
PATCH — editorial or documentation-only corrections.
A module’s own changelog — where it has one — is published as the final
section of its request document, independent of every other module’s. Every module
publishes at a single, stable "latest" URL (e.g. /mikadiv-vib, /kafe,
/streamld), updated in place as new versions are released — dated snapshot URLs for
citing a frozen historical version are minted only once a module actually
reaches a second version.