The Shareholder Rights Directive II (SRD II) gave issuers the right to identify and engage with their investors. Most German-listed issuers and their agents will have encountered the shareholder identification process at least once as a result. 

With MiKaDiv launching in 2027, that same data will no longer just inform investor engagement. It will be submitted to the German tax authority. If the underlying data has gaps, the consequences can extend across the custody chain.

The European Commission’s recent public consultation on the SRD regulation highlighted certain vulnerabilities that need to be addressed. Multiple custody chain participants, inconsistent definitions, fragmented messaging formats, and cross-border complexities were just a few of the concerns raised.

These are some of the issues that make shareholder data difficult to assemble accurately today, and they raise a significant consideration for MiKaDiv compliance.

In this article, we explore what MiKaDiv is, the data quality challenge and how Proxymity can close the gap.  

What is MiKaDiv? 

MiKaDiv (Mitteilungsverfahren Kapitalertragsteuer auf Dividenden aus Aktien und Hinterlegungsscheinen) is Germany’s new mandatory notification procedure for withholding tax on dividends from shares and depositary receipts. 

It was introduced under the Abzugsteuerentlastungsmodernisierungsgesetz (AbzStEntModG), the Withholding Tax Relief Modernisation Act, and is designed to replace Germany’s paper-based tax certificate system with a fully digital, auditable reporting chain. The regulation was partly introduced in response to Germany’s experience with cum-ex and cum-cum tax fraud, where the opacity of the custody chain made it possible to claim multiple refunds on withholding tax that had only been paid once. 

Here are the key facts of the regulation: 

1) Go-live: 1 January 2027, applying to dividend income received after 31 December 2026 

2) Reporting authority: Bundeszentralamt für Steuern (BZSt), the German Federal Central Tax Office 

3) Legal basis: AbzStEntModG: Withholding Tax Relief Modernisation Act 

4) Primary obligation: German-listed issuers must submit shareholder identification data to the BZSt no later than four to six weeks after dividend distribution 

5) Connection to EU FASTER: MiKaDiv is Germany’s national implementation ahead of the broader EU-wide initiative on withholding tax relief harmonisation 

The original go-live date was delayed several times before being set for 2027. This was mainly to allow for alignment with the EU FASTER directive’s framework and to accommodate industry requests for clearer technical guidance, particularly around complex cross-border arrangements. 

What does MiKaDiv require to be reported? 

MiKaDiv reporting goes well beyond a point-in-time snapshot of holdings. It requires granular and auditable information on beneficial ownership, including the full custody chain structure with legal entity identifiers for each participant. 

Specifically, you must submit: 

a) Identity of shareholders at the dividend record date 

b) Beneficial ownership data across the custody chain 

c) Securities details attributable to each beneficial owner 

This level of granularity matters for one specific reason: MiKaDiv reporting is a prerequisite for subsequent withholding tax reclaims and relief at source. Getting the data wrong does not simply create a compliance problem.

It means your investors may lose access to withholding tax relief to which they are entitled, with no mechanism to recover it unless the submission is corrected and resubmitted. 

To learn more about the MiKaDiv regulation, how it impacts market participants, and the timelines, download our regulation guide.  

What are the real challenges to complying with MiKaDiv? 

Most published commentary on MiKaDiv focuses just on the reporting mechanics, i.e what and how to file through the BZSt interface.

This outlook misses a harder, upstream problem: the quality and completeness of the data that feeds into that report.

1. Limited visibility into mismatches in shareholder data 

Shareholder identification data passes through multiple layers of the custody chain before it reaches the issuer or issuer agent. If a nominee discloses a position that does not match what their custodian reported at the layer above, that discrepancy is not visible from either response in isolation. 

Surfacing a mismatch like this typically requires contacting each upstream custodian individually, asking what they disclosed, and manually comparing it line by line against what the downstream party reported. At the scale most issuers are dealing with, this is rarely done in practice, which means discrepancies can sit undetected within the data that ultimately informs a BZSt filing. 

2. Inconsistent identifiers and data formats across the custody chain 

Each intermediary at different levels of the chain uses unique identifiers to refer to themselves or to one another. A bank at one level may identify itself using a BIC code. The custodian one level up may refer to that same bank using a proprietary internal reference. A third party may use an LEI. 

This inconsistency extends to the format the data itself arrives in. Some intermediaries respond using ISO 20022. Others use ISO 15022. Some use proprietary or non-structured formats entirely. Each format requires different handling before the data can be compared. 

Comparing data across the chain is not a reliable process without a layer that normalises both identifiers and formats into a common structure.

Two entries referring to the same entity can appear to be different entities, or two different entities can appear to match, and two holdings that should align may appear to mismatch simply because they arrived in different formats. None of these outcomes support a filing you can stand behind with confidence. 

3. Responses are incomplete, and arrive without a consolidated view of timing 

Not every intermediary in the custody chain responds to a disclosure request, and those that do respond rarely do so at the same time. Some lack the technical capability to respond. Others may not recognise the obligation. Some respond within hours, others take days, and a portion may not respond within the required window at all. 

Without a mechanism that tracks which responses have arrived, which are outstanding, and how that picture is changing in real time, the issuer agent has no reliable way of knowing how complete their dataset is at any given point, or when it is likely to be complete.

Making a filing decision in that environment means either waiting indefinitely or proceeding with a dataset that has unquantified gaps, gaps that neither the issuer nor the BZSt can identify until a query is raised. 
 

4. Nominee and omnibus layers obscure beneficial ownership 

In many cases, what arrives from an intermediary is not the identity of the underlying beneficial owner, but a position held in an omnibus or nominee account. The beneficial owners behind that account are not visible in the response itself.  

You may have to work through those additional layers to reach the actual investor, which means requesting further information, waiting for further responses, and repeating the identifier normalisation challenge at each additional level. Every extra layer is another opportunity for data to be incomplete, delayed, or mismatched. 

5. No audit trail in manual workflows 

When reconciliation is performed manually, through spreadsheets, email exchanges with custodians, and offline identifier mapping, there is no systematic record of what was checked, what discrepancy was found, and what decision was made about whether to include or exclude a particular holding. If the BZSt queries the filing, the issuer or issuer agent cannot demonstrate the process that produced it.

An automated infrastructure generates that audit trail as a natural by-product of the reconciliation process, creating a defensible record of every decision made before submission. 

6. Point solutions provide no reconciliation transparency 

Most providers in the MiKaDiv market offer a solution that handles the submission layer, including collecting responses, formatting the data, and transmitting the file to the BZSt. 

What they typically do not offer is visibility into the quality of the data behind that submission. If the data is incomplete, if identifiers or formats have not been normalised, if upstream and downstream positions do not align, a point solution will still produce a file. It will not necessarily tell you whether what is in that file reflects an accurate picture. 

A connected infrastructure like Proxymity surfaces those gaps before submission, giving the issuer or issuer agent the control to decide what goes to the regulator. 

How Proxymity approaches MiKaDiv compliance 

Our approach to MiKaDiv is built on the same infrastructure that already powers SRD II shareholder identification across more than 105 markets. The data foundation exists, and the connectivity into the custody chain is already established. 

The upstream data foundation 

We are integrated with Clearstream Frankfurt, tier-one custodians, and 2,500+ intermediaries, covering the full custody chain from CSD through to the beneficial owner. The shareholder data feeding your MiKaDiv submission flows through that existing network. It is not assembled from scratch for a one-off filing but drawn from a connected, real-time source that is already live and operating. 

Automated reconciliation before submission 

Our reconciliation capability normalises identifier codes across intermediaries, mapping BIC codes, LEIs, and proprietary references to a common reference framework, and surfaces discrepancies directly in the platform’s UI before anything is submitted. You have full visibility into which data has been successfully reconciled and which has not.  

Nothing goes to the BZSt without you explicitly accepting it. The decision remains yours. We make the data quality visible. 

Compliant submission via accredited infrastructure 

Once your data is reconciled and accepted, we translate it into the required encrypted XML format and submit it directly to the BZSt via the DIP interface. We are a BZSt-accredited software vendor for MiKaDiv submissions, and we are actively engaged with BZSt’s MiKaDiv working group.  

We also ensure shareholder data is complete and verified ahead of payment deadlines, reducing reliance on post-payment reclaim processes. 

Built for what comes next 

Proxymity’s MiKaDiv capability is designed to connect every stage of the process, from the upstream shareholder data through to submission, rather than addressing the reporting layer in isolation. This means the infrastructure validating and preparing your data is part of the same connected environment that delivers it, rather than a separate system bolted on at the point of filing. 

To learn more about Proxymity’s MiKaDiv compliance solution, get in touch or download our compliance resources. 

MiKaDiv and EU FASTER: What comes next 

MiKaDiv does not exist in isolation. It is Germany’s national implementation ahead of the EU FASTER Directive, which aims to harmonise withholding tax relief procedures across all EU member states and reduce the friction that currently makes cross-border tax reclaims slow, expensive, and inconsistently administered. 

The delay from 2026 to 2027 was partly driven by a strategic effort to align MiKaDiv’s framework with FASTER, including harmonised data elements for dividend payments, transaction details, and beneficial owner data.  

If you build for MiKaDiv compliance now using connected, automated infrastructure, you will be significantly better positioned for FASTER when it introduces its own obligations across the wider EU.  

A point solution that meets only the minimum required by MiKaDiv today will need replacing soon. 

Frequently asked questions (FAQs) about MiKaDiv 

Who does MiKaDiv apply to? 

MiKaDiv applies to three groups across the dividend value chain. 

a) German-listed issuers are required to submit shareholder identification data to the BZSt at the time of their profit distribution resolution under Section 45b paragraph 9 EStG. The data must be current and accurate at the point of filing. 

b) German paying agents and custodians are responsible for reporting investment income and capital gains data directly to the BZSt in the mandated digital format, ensuring the positions they submit are accurate and reconciled. 

c) Foreign financial institutions and global custodians are also within scope if they hold or manage German securities on behalf of clients, regardless of where they are located. A UK custodian or US broker holding shares in a DAX-listed company must provide beneficial ownership and custody chain data to their German paying agent. This extraterritorial reach is frequently underestimated by non-German institutions. 

When does MiKaDiv come into force?  

MiKaDiv comes into force on 1 January 2027 and applies to dividend income received after 31 December 2026. The original 2026 go-live date was delayed to allow for alignment with the EU FASTER directive and to provide the industry with additional time to implement the required technical and operational changes. 

What is the difference between MiKaDiv and EU FASTER?  

MiKaDiv is Germany’s national regulation for digital dividend tax reporting, coming into force in 2027. EU FASTER is the broader EU-wide directive aimed at harmonising withholding tax relief procedures across all member states. MiKaDiv was specifically designed with alignment to FASTER in mind, and firms building MiKaDiv compliance infrastructure today should ensure it is also capable of accommodating FASTER obligations when they take effect. 

What happens if MiKaDiv data is incorrect?  

If the data submitted to the BZSt under MiKaDiv is incomplete or inaccurate, investors may lose access to withholding tax relief they are legitimately entitled to, as MiKaDiv reporting is a prerequisite for withholding tax reclaims and relief at source.

This may lead to regulatory scrutiny.

Additionally, the correction and resubmission processes can create a significant operational burden for issuers and their agents. 

What are the penalties for non-compliance?  

Penalties for MiKaDiv non-compliance are established under German tax law and can include financial fines for failure to submit required data accurately or on time, as well as potential legal liability for intermediaries that fail to meet their reporting obligations. Investors whose tax reclaims are rejected as a result of non-compliant or inaccurate reporting by their custodian may raise concerns with that custodian regarding the accuracy of the data submitted on their behalf. For firms serving institutional clients with strict operational standards, the reputational consequences of non-compliance may be the most material risk of all.