MiKaDiv 2027: Your top questions, answered

 

How is my institution affected by MiKaDiv?

MiKaDiv requires that German dividend withholding tax information is reported electronically to the Federal Central Tax Office (BZSt) along the custody and payment chain. This affects not only German paying agents, but also foreign banks and intermediaries that hold or process German securities for their clients. 

If you act anywhere in the custody chain for German equities – as German reporting bank, foreign custodian or intermediary – you will most likely need to create, validate or pass on MiKaDiv reports and responses.

Do we fall under the MiKaDiv reporting obligation – and in which role?

MiKaDiv distinguishes between three main roles: 

• German reporting bank: German institutions with the direct obligation to report to BZSt. 

• Foreign bank: Non‑German banks holding German securities which must report in the specific format of their German custodian(s). 

• Intermediary bank: Institutions in between, validating omnibus data and passing reports along the chain. 

 

Our MiKaDiv solution models these roles explicitly. During onboarding, we assess your custody setup and define which roles apply per legal entity and per tenant, so that reporting logic and interfaces match your actual responsibilities. 

What exactly does RAQUEST’s MiKaDiv Reporting solution cover – and what is out of scope? 

In scope is the entire MiKaDiv reporting lifecycle for capital income: 

• Import of taxed income, position and transaction data from upstream systems 

• Role‑based reporting logic (German reporting bank, foreign bank, intermediary) 

• Creation of MiKaDiv‑compliant reports 

• Validation, approval workflows and audit trail 

• Processing of responses from BZSt and from the payment chain, including status handling 

 

Out of scope (by design) are: 

• MiKaDiv shareholder reporting by the issuer  

• The calculation of German tax itself 

• The creation of German tax certificates 

 

These steps remain in your existing tax calculation and certificate systems, which we connect via interfaces. 

How does MiKaDiv change the current German tax certificate and dividend reporting processes? 

MiKaDiv extends and partly replaces traditional German tax certificates with a digital, event‑based reporting process: 

• More granular data is required (holding periods, custody chain, LEIs, financial arrangements, etc.). 

• German reporting financial institutions must report following the MiKaDiv formats and transmit electronically. 

• For all non-German investors, MiKaDiv becomes the pre‑condition for subsequent tax reclaim processes. 

 

With RAQUEST, MiKaDiv is not a standalone system. We embed MiKaDiv reporting into your existing tax workflows, re‑use data and rules from reclaim and documentation modules, and ensure consistency between certificates, reports and reclaim activities. 

How does RAQUEST’s MiKaDiv solution integrate with existing core banking, custody and tax systems? 

Our MiKaDiv solution is built as an integration‑ready component: 

• Data input: Client imports beneficial owners, accounts, securities, transaction and tax data from core banking and custody systems via file interfaces or APIs. 

• Data output: We generate MiKaDiv reports and responses that can be fed back into your tax, reporting or archive systems. 

• Reuse of logic: Residency status, beneficial owner data, entitlement rules and documentation already used in reclaim processes can be re‑used for MiKaDiv. 

 

In practice, we define a lean set of technical interfaces in a joint workshop and implement them once as part of the project – the solution is then ready for MiKaDiv and future regimes like FASTER on the same base platform. 

Can RAQUEST support complex custody chains, omnibus accounts and overclaiming controls? 

Yes, MiKaDiv is explicitly designed for multi‑level custody chains and omnibus structures, and our software reflects that: 

• We import omnibus account data and client‑level positions. 

• The system validates MiKaDiv reports against omnibus balances to detect overclaiming and inconsistencies. 

• Role‑based logic ensures that foreign, intermediary and German reporting banks see exactly the information and actions relevant for their position in the chain. 

 

This helps you maintain control over risk‑relevant points such as overclaiming, securities lending and short‑term trading positions. 

How do RAQUEST’s MiKaDiv modules interact with the BZSt and with upstream/downstream custodians? 

For German reporting banks, RAQUEST: 

• Creates BZSt‑compliant MiKaDiv reports (FSAK‑FM) 

• Supports the technical submission flows via ELMA and, going forward, DIP.KAFe 

• Receives and processes BZSt responses, including error handling and re‑submission workflows 

 

For foreign and intermediary banks, RAQUEST: 

• Creates and validates files in the specific import/export schema required by each custodian. 

• Imports responses from the chain and reconciles them with your original requests. 

 

Technical transmission to custodians or to the BZSt can be implemented either via existing bank middleware or, if required, in a dedicated project.

Can MiKaDiv be combined with existing withholding tax reclaim processes in one end‑to‑end workflow? 

This is one of the key strengths of our approach. We offer: 

• A MiKaDiv Reporting module for the German regime 

• A Reclaim module for withholding tax relief and refund processes (including self‑submitter capabilities) 

• Shared data and rules between reporting and reclaim, so MiKaDiv results can directly feed into reclaim, forwarding or client‑facing documentation 

 

For German reporting banks, we also support the generation of tax vouchers / ordinal numbers and the integration of MiKaDiv feedback into your reclaim and billing processes. The result is a single, consistent tax lifecycle instead of parallel, disconnected tools. 

What is the typical implementation effort and timeline to go live with RAQUEST’s MiKaDiv solution?

The exact effort depends on your system landscape and roles, but typical MiKaDiv projects follow four phases: 

1. Analysis & role mapping: Clarify legal roles, account structures and reporting responsibilities. 
2. Configuration & integration: Adapt rules, set up tenants and roles, define and implement interfaces.
3. Testing & validation: Run representative test cases, validate field mappings and submission flows.
4. Go‑live preparation: User training, operational procedures, monitoring and fallback concepts. 

 

For a bank with one to two legal entities and standard interfaces, we usually see a project duration of several months, aligned with regulatory timelines and internal release cycles.