Why withholding-tax software has to work differently for KVGs

Withholding-tax reclaim is a process shaped over decades by banks and custodians. The software that maps it carries that origin. It works — as long as the user knows the depositories, keeps the central custodian in view and can reconstruct the custody chain of a position without asking. That is exactly the world a capital management company (KVG) now steps into when it takes the process on itself. And it is a different world than the software assumes.

This piece describes why the same system that runs reliably at a bank hits limits at a KVG — and what an as-is analysis reveals: not that the software fails, but that a dataset nobody used to need is missing.

The custodian as the owner of the process

Historically, the recovery of withholding tax sat with the custodian. The custodian knew the depositories, held the positions, knew the intermediaries a security had passed through. The KVG stuck to investment law and strategy; operational responsibility for the custody chain stayed further down. That meant the dataset a reclaim system needs lived inside the bank itself — not as an export, but as a living part of the accounting system.

Software for withholding-tax reclaim was built for exactly that situation. It assumes the custody chain is available per position: every depository, every central custodian, every transfer during the year. Where that data is missing, the system asks for it — at the very point where, in a bank, the position master sits.

What changes when the KVG takes the process on

When a KVG decides to steer reclaim itself — because it uses several custodians, wants to steer relief-at-source strategically, or has to handle reporting duties such as MiKaDiv on its own — ownership shifts. Suddenly a team at the KVG understands the reclaim process, but does not necessarily hold the custody chain in its own house.

The data still sits with the custodians — distributed, in different formats, at different granularity. A KVG with several dozen funds and two or three custodians does not get a consistent picture of the custody chain. It gets fragments. And those fragments are exactly the dataset the reclaim system takes for granted.

The consequence is not that the software is bad. The consequence is that the input dataset is missing — and that this gap is felt in operations as a software failure, although it is a data-ownership problem.

The custody chain as an input dataset — and why it is often missing

The custody chain is the sequence of depositories a position passes through during a tax year. It starts at the central custodian, may run through an intermediate depository, and ends at the depositary holding the position. For reclaim, this chain is decisive: it determines which withholding tax applies, which relief applies, and where the refund is claimed.

At a bank, this chain lives in the booking system. At a KVG, it lives — if at all — in a mix of custodian reports, manually maintained spreadsheets, and individual cases the fund manager still remembers. That is not a criticism of the KVG. It is the consequence of a historical division of labour that is now being renegotiated.

Where the custody chain is missing, three typical symptoms appear:

• Claims are filled with placeholders because the depository is entered “somewhere”.
• Refunds sit idle because no one can clarify the responsibility of the intermediate depository.
• Relief at source is not applied, or applied late, because the chain is not available at the cutoff date.

These symptoms are not the real problem. They are signs that a dataset the system expects as input does not exist in the house.

What this means for configuration, business teams and development

Anyone introducing a reclaim system at a KVG has to treat the custody chain as an input dataset — not as a nice-to-have. That has consequences for three groups.

For configuration, the interface to the custodians is not just another import; it is the critical upstream stage. It has to handle format tolerance, history and transfers — and it has to recognise when a chain is incomplete, instead of silently filling the gap.

For the business team, someone has to own the quality of the custody chain. That is often a new role. The custodian used to own it implicitly. Now the KVG needs it explicitly — with a name, with a process, and with the right to query when gaps appear.

For development, the system has to cope with incomplete chains. An error report saying “depository missing” is more valuable than an automatic plausibility check that hides the gap. Making the gap visible enables correction. Hiding it produces a refund next year that no one can explain anymore.

How to start: questions for the as-is analysis

Before a software is selected or configured, an as-is analysis that puts this dataset at the centre is worthwhile. The questions are plain, the answers usually uncomfortable.

• Who in the house knows the custody chain per fund at the cutoff date — by name?
• In which format do the custodian reports arrive, and how current are they?
• How are transfers between depositories over the year captured?
• Who decides, when gaps appear, whether to query or to set placeholders?
• Is there a place where the chain remains traceable across the year — or does it live only in the custodian’s head?

Anyone who cannot answer these questions does not have a software problem. They have an ownership problem. And that is not solved by a tool, but by a decision on who in the house maintains the custody chain.

An example that shows the gap

Picture a KVG with three custodians and around forty funds. In year X a position is moved from one depository to another over the summer — a completely normal event. In December a reclaim is due. The reclaim system queries the custody chain at the cutoff date and gets an answer: one depository. Which of the two is in the custodian’s report — which, in this form, does not exist in the house.

What happens? The case handler enters one of the two depositories, usually the one current at the cutoff date. The claim is filed. In the best case it goes through. In the more realistic case it does not, because the competent party expects the other depository. No one did anything wrong — the dataset that would explain the difference simply was not there.

This example is invented, but it is typical. It shows that the damage does not arise at the software, but at the point where the house decides how to deal with a gap. Anyone who knows that point before introducing the system avoids most of the follow-on damage.

What we learn from this

Withholding-tax reclaim is not an isolated process. It depends on a dataset that historically sat with the custodian and that a KVG taking the process on has to build first. Software cannot fill this gap — it can only make visible where it exists.

Anyone accompanying a KVG through this introduction should therefore not start with the software, but with the question of who in the house knows the custody chain. Almost everything else follows from that answer: the interface, the configuration, the role of the business team, and the way the system handles gaps.

If you face the same question — after a custodian migration, a system change, or building an in-house reclaim team — a first conversation is worthwhile. We look at where the custody chain lives today and what it takes to turn it into a reliable input dataset.