From asking for data to sharing data
In its programme Participatiewet in Balans, Divosa, the Dutch association of municipal social services, is working towards a simpler and more humane Participation Act (Participatiewet), the law that governs social assistance in the Netherlands. One of the tracks looks at how municipalities collect data from residents. Luciënne Middelhof, programme manager for the Participation Act and enforcement at Divosa, recently wrote about this in the blog Van gegevens vragen naar gegevens delen: de impact van ID-wallets (from asking for data to sharing data: the impact of ID wallets).
On 4 November we co-hosted the webinar Fewer bank statements thanks to ID wallets with Divosa. This post sums up what we showed there: how a resident can share their financial situation with PSD2 and the Yivi wallet instead of bank statements, and why that makes the relationship between resident and municipality fairer.
The problem with bank statements
Anyone applying for social assistance (bijstand) usually hands in bank statements covering several months. The caseworker leafs through them looking for income and assets. That causes four problems, and a fifth one underneath.
Municipalities see far more bank data than needed when someone applies for social assistance
Unequal information position: the municipality does the maths, but can the citizen check for themselves whether they are entitled?
Sources: AP, Uitkering en privacy; AP, brief aan VNG over controle van bijstandsgerechtigden (25 november 2021); Participatiewet art. 17.
That fifth problem is mentioned less often: an unequal information position. The municipality does the maths, but the resident cannot check beforehand whether they are entitled and to what amount.
How it works: PSD2 categorises, Yivi shares
Since the European payment services directive PSD2, you can give a licensed provider permission to retrieve your account information. We use that principle to turn a pile of transactions into a handful of meaningful numbers that the resident manages in their own wallet.
- Connect the account. The resident logs in to their own bank through enablenow, a licensed PSD2 account information service provider, and gives one-time permission to retrieve the transactions.
- Categorise. Every transaction is put into a fixed category: salary, state pension, housing allowance, childcare allowance, rent, health insurance, groceries and so on. Transfers between the resident’s own accounts are ignored.
- Summarise. For each category the average net amount per month is calculated over the last twelve full months, rounded to ten euros. No individual transactions, descriptions or counterparty names are included.
- Revoke access. As soon as the amounts are calculated, the consent at the bank is revoked and the bank data is deleted.
- Choose. The resident sees all amounts and chooses which cards to add to their Yivi app. The cards are valid for 90 days, because financial data goes stale quickly.
The result is a set of small cards, one per group: income, allowances, housing, insurance, loans, taxes, essential expenses and so on. Every card is digitally signed. A caseworker no longer has to check a PDF: an edited amount is caught immediately.
How categorisation works
A bank statement is a long list of amounts with descriptions. Categorisation turns that list into a fixed structure that is the same for everyone. For this we use the E1 categories of enablenow: a tree of top-level groups such as income, benefits and allowances, housing, insurance, loans, essential expenses and lifestyle, with specific categories underneath such as income, state pension, benefits and allowances, housing allowance or housing, rent.
In the example every transaction gets a category, including the pharmacy, the trade union and the supermarket. But only the red, blue and orange categories are needed for the scheme. The rest stays on the resident’s phone: the municipality does not ask for it, and so never sees that a trade union fee or a pharmacy contribution was paid. Even within one card the resident shares only what is asked for: the healthcare allowance sits on the same card as the housing allowance, but is not shared.
- One category per transaction. Based on the counterparty, the description and the type of payment, among other things, every transaction gets one category. Transactions the model is too unsure about, or in another currency, are left out.
- Each group becomes a card, each category an attribute. The Benefits and allowances card, for example, holds the healthcare allowance, the housing allowance and the childcare allowance as separate attributes. A municipality can therefore ask for the housing allowance without seeing the healthcare allowance.
- Net and signed. A positive amount was received, a negative amount was paid. Rent of 1,050 euros a month shows up as -1050. A refund gets the category of the original payment, and a repaid allowance stays an allowance, so both cancel out neatly.
- No derived judgements. No totals, yes/no flags or risk scores are calculated. The card holds only the averages per category and the period they cover. What those amounts mean for a scheme is decided by the law, not by the categorisation.
Because the same structure applies to every resident and every bank, the calculation rules of a scheme can build on it directly. Whether the resident connects the account on their own, together with a caseworker at the desk or with help from their financial guardian: the result is the same set of categories, and it is just as readable for the resident as for the municipality.
Municipalities do not have to build this categorisation themselves. They can use an existing categorisation engine, such as the E1 engine of enablenow we use in the demo. But at its core a categorisation is a public list of categories with rules for sorting transactions. Municipalities can therefore also develop and maintain one together as open source, so that anyone, including the resident and their guardian, can check why a transaction ends up in a particular category. What matters most is that the issuer of the cards and the municipality use the same, public structure.
Share only what the law asks for
Because the data sits in the wallet per category, a municipality can ask for exactly what a scheme needs, and nothing more. For an indication of the right to social assistance, that is the income that counts under articles 31 and 32, the date of birth (for the age group and the state pension age) and the postcode (to establish that the applicant lives in the municipality, article 40). Spending on healthcare, sports, donations or a trade union stays on the resident’s phone.
The same cards work for other schemes too. Besides social assistance, the demo we showed covers a municipal low-income scheme and remission of municipal and water authority taxes. For tax remission, rent, the health insurance premium and the healthcare allowance also count, for example. Each scheme asks for its own set of categories, and the app shows the resident beforehand which ones those are.
The same information position for resident and municipality
This is where we see the biggest gain. The calculation rules in the demo are based on the legal texts in the regelrecht corpus of the Dutch Ministry of the Interior, using the standard amounts in force on the day of the check. The resident can therefore run the same rules, with the same data, themselves. Before applying, they already see whether they are likely to be entitled and what the municipality will see.
It remains an indication, not a decision. Assets, the youth standards, exclusion grounds and a partner’s income are not part of the demo yet, and a twelve-month average is not the same as this month’s income. For those parts the caseworker is still needed.
Laws and regulations as executable rules
The calculation rules do not have to be programmed again in every application. They can be integrated from a shared, open source, such as RegelRecht by the Dutch Digital Service (Nederlandse Digitale Dienst). RegelRecht records laws as machine-readable rules and executes them, and every outcome can be traced back to the article of law it is based on. Scenarios test whether the executable version of a law produces the outcome the legislator intended, where possible using worked examples from the explanatory memorandum.
A social assistance scenario in the RegelRecht demo. The engine shows the outcome and every step of the reasoning, with the law or regulation each step refers to. Source: demo.regelrecht.rijks.app
That fits the cards in the wallet exactly: the wallet supplies reliable data per category, the executable law decides what that data means. Municipalities can add their own policy rules, such as the income limit of a low-income scheme. And because the rules are open, the resident, or their guardian, can make the same calculation as the municipality.
RegelRecht is not finished yet. It is an exploration into transparent, executable legislation, and not every law has been fully recorded and tested. But the direction is clear, and combining it with a wallet shows what it delivers: the same rules and the same data on both sides of the desk.
With or without help: resident, caseworker and guardian
Not everyone applies for social assistance on their own. In this group in particular, many residents have a financial guardian (bewindvoerder), a debt counsellor or a social worker at their side. The approach works in each of these situations, because the resident gives the consent and the cards live on their own phone.
- On their own, at home. The resident connects their account, checks the amounts, calculates their own indication and shares the cards with their application.
- Together with the caseworker. At the desk or during a home visit, the caseworker shows a QR code. The resident scans it and sees in their app exactly which data the municipality asks for. After approval the caseworker has verified amounts within seconds, without copies in the file.
- With a financial guardian or debt counsellor. Under financial guardianship, money often flows through a managed account. The guardian can connect the right accounts together with the resident and go through the amounts. The categories show at a glance what comes in and what the fixed costs are, and debts and debt collection have their own category.
Sharing data on behalf of someone else, such as a guardian acting for their client, requires a form of authorisation in the wallet. That is a next step we would like to explore further with municipalities, guardians and Divosa.
And as Luciënne Middelhof rightly writes: personal contact remains just as important, especially for people with fewer digital skills. A wallet does not replace the caseworker. It removes the retyping, the checking of PDFs and the unnecessary access, so that more time is left for the conversation.
Privacy by design
- Data minimisation. The municipality sees only the categories the scheme asks for, never individual transactions.
- No central storage. The bank data is deleted after the calculation. The cards live only on the resident’s phone.
- Guaranteed authenticity. Every card is signed by the issuer. It cannot be changed without invalidating the signature.
- The resident in control. For every request, the resident sees who wants to know what, and decides whether to share. That matches the data minimisation required by eIDAS 2.0.
Get started
Divosa asks municipalities how many bank statements and supporting documents they request each year, and which of them could eventually be dropped. We think that for most bank statements the answer is: all of them. Do you work at a municipality, a financial guardianship office or a debt counselling organisation and would you like to try this in practice with us? Get in touch.