Why withholding-tax software has to work differently for KVGs

Banks and custodians shaped withholding-tax reclaim over decades, and the software built for it still shows that. It works as long as the user knows the depositories, keeps track of the central custodian and can reconstruct the custody chain of a position without asking anyone. A capital management company (KVG) that takes the process on itself today works under different conditions than the software assumes.

In this piece I explain why the same system that runs reliably at a bank hits limits at a KVG, and how an as-is analysis usually shows that the software is fine and a dataset nobody used to need is missing.

The custodian as the owner of the process

Historically, recovering withholding tax was the custodian's job. The custodian knew the depositories, held the positions and knew which intermediaries a security had passed through. The KVG stuck to investment law and strategy, and operational responsibility for the custody chain stayed further down. So the dataset a reclaim system needs was already inside the bank, as part of its running accounting system rather than as an export.

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 point where, in a bank, the position master sits.

What changes when the KVG takes the process on

Some KVGs decide to run reclaim themselves, for example because they use several custodians, want to manage relief at source strategically, or have to handle reporting duties such as the new capital-gains-tax reporting obligation under §§ 45b, 45c EStG on their own. Ownership then shifts. A team at the KVG now understands the reclaim process but does not necessarily hold the custody chain in-house.

The data still sits with the custodians, spread across them in different formats and at different granularity. A KVG with several dozen funds and two or three custodians gets fragments of the custody chain, not a consistent picture. The reclaim system, however, takes the full picture for granted.

That does not make the software bad. The input dataset is missing, and in daily operations the gap looks like a software failure even though 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, the chain 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 anywhere, in a mix of custodian reports, manually maintained spreadsheets and individual cases the fund manager still remembers. I don't mean that as a criticism of the KVG. It follows from a historical division of labour that is now being renegotiated.

Where the custody chain is missing, three symptoms usually show up:

• 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.

Each of them means 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 a required input dataset. That affects three groups.

In configuration, the interface to the custodians is the critical upstream stage rather than one import among many. 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.

In 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 has to assign it explicitly, with a name, a process and the right to query when gaps appear.

In development, the system has to cope with incomplete chains. An error report saying “depository missing” is more useful than an automatic plausibility check that hides the gap. A visible gap can be corrected. A hidden one produces a refund next year that no one can explain anymore.

How to start: questions for the as-is analysis

Before anyone selects or configures software, it pays to run an as-is analysis centred on this dataset. The questions are simple. The answers are 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 stays traceable across the year, or does it live only in the custodian’s head?

If you cannot answer these questions, you have an ownership problem. A tool will not fix it. The house has to decide who maintains the custody chain.

An example that shows the gap

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

The case handler enters one of the two depositories, usually the one current at the cutoff date, and the claim is filed. In the best case it goes through. More realistically it does not, because the competent party expects the other depository. Nobody did anything wrong. The dataset that would explain the difference simply was not there.

The example is invented, but typical. The damage happens where the house decides how to deal with a gap, not in the software. If you know that point before the rollout, you avoid most of the follow-on damage.

What we learn from this

Withholding-tax reclaim 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 show where it is.

So anyone guiding a KVG through this rollout should start by asking who in the house knows the custody chain, and only then look at software. 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 are facing the same question, whether after a custodian migration, during a system change or while building an in-house reclaim team, a first conversation is worth it. We look at where the custody chain lives today and what it takes to make it a reliable input dataset.