This is the second in a three-part series on the KSA’s tightened duty of care requirements for Dutch-licensed operators. The first post – Evidence-based income verification: how open banking meets the KSA’s new standard – covered the shift from self-declarations to verifiable supporting documents. This post focuses on what happens next: getting the income calculation itself right.

Verifying that a player has income is one thing. Correctly calculating how much of that income should count towards their net deposit limit is another – and it’s where the Dutch gambling regulator, KSA, has found operators getting it wrong.

The regulator’s Financial Capacity Assessments: Duty of Care guidance doesn’t just require operators to use verifiable supporting documents. It sets out a detailed framework for what counts as income, what doesn’t, and what must be excluded from the calculation entirely. The list of exclusions is long, the margin for error is narrow, and the consequences of getting it wrong are clear: it’s a compliance breach.

For operators relying on manual document review, this creates a real problem. Every payslip, tax return, and bank statement needs to be interpreted correctly – and the KSA has already flagged multiple examples of operators failing to do so.

What the KSA requires operators to exclude

The KSA’s guidance sets out a non-exhaustive list of income categories that must be excluded when determining a player’s net deposit limit. These aren’t suggestions – they’re mandatory exclusions:

• Borrowed money. Any funds the player has borrowed, regardless of the source.
• Earmarked income. This includes child support (kinderalimentatie), child benefits (kinderbijslag), personal care budget (persoonsgebonden budget, PGB, housing allowance (huurtoeslag), insurance benefits (verzekeringsuitkeringen), tax office allowances (belastingtoeslagen). These are payments designated for specific purposes – not discretionary income.
• Partner or children’s income. A player’s affordability must be assessed on their own income, not their household’s.
• Business expense reimbursements. Money received to cover work-related costs isn’t personal income.

Beyond income exclusions, the KSA also distinguishes between income and liquid asset receipts. The following are considered liquid assets and cannot be counted as income:

• Transfers from a savings account to a current account.
• Non-recurring receipts from private third parties – such as peer-to-peer payment requests (Tikkies), an inheritance, a gift, or a refund from a cancelled purchase.
• Withdrawals from another gambling provider’s gaming account.

And at the other end, non-liquid assets – home equity, business equity, or other property – may not be included in the net deposit limit calculation at all. Only liquid assets (savings) can be factored in, and even then, the KSA warns that a player using more than 30% of their liquid assets for gambling is a sign they can no longer bear the financial consequences of their behaviour.

Where operators are getting it wrong

The KSA hasn’t just outlined what operators should do – it has flagged specific errors it has already observed. These aren’t hypothetical risks; they’re mistakes operators are making now.

Incorrect analysis of tax returns. The KSA found operators calculating a player’s net income from a tax return by subtracting the total tax assessment rather than the correct line item (income tax and national insurance contributions, or inkomstenbelasting en premie volksverzekeringen) from aggregate income. This is a technical error, but it results in an incorrect net income figure – and therefore an incorrect deposit limit.

Miscounting self-employed income. For business owners, the KSA requires assessments to be based on net income, not gross. But the regulator has observed operators counting gross dividend payments from a player’s own business as net income, and counting assets on the business balance sheet as personal income. Neither is correct.

Merely confirming self-employment. In some cases, the KSA found that operators validated a self-employed player’s reported income by simply confirming that they had a registered business – without verifying the actual income figure. Having a business doesn’t tell you what it earns.

Including earmarked income. Some operators have failed to separate tax office allowances and benefits from regular income. A player receiving PGB payments, housing allowance, or child support may appear to have a higher income than they actually do if these are included in the affordability calculation.

These errors matter because they inflate the net deposit limit. A player who appears to have €1,500 of monthly income might have just €900 of qualifying income once exclusions are applied – and since the deposit limit is capped at a share of that, the gap is the gap between compliance and breach.

Why manual processes make this harder than it needs to be

The challenge isn’t that operators don’t understand the rules. It’s that applying them correctly to every player, every time, using manual document review, is operationally difficult.

A payslip is relatively straightforward – but even then, operators need to distinguish between gross and net, and between regular salary and one-off payments. A tax return is harder: Dutch tax returns are complex documents with multiple income boxes (Box 1, Box 2, Box 3), and extracting the right figure requires specific knowledge of the Dutch tax system. Self-employed income is harder still: an entrepreneur’s personal income may be spread across dividends, management fees, and expense reimbursements, any of which could be miscounted.

And then there’s the exclusion problem. A player’s bank account may show incoming payments from the Belastingdienst (tax authority), SVB (social insurance bank), or their municipality – but a compliance analyst reviewing a static bank statement needs to know which of those are qualifying income and which are earmarked benefits that must be excluded. A housing allowance credit (huurtoeslag) looks like income on a statement unless you know it isn’t.

The iGaming Business report on the KSA’s February 2025 letter to operators captured the problem neatly: income statements typically show a person’s gross salary without including deductions made to tax, pension contributions, and other items – and some operators were accepting these as the basis for increasing deposit limits.

Scale this across thousands of players, and the risk of error compounds. Every manual review is an opportunity for misclassification, and every misclassification is a potential breach.

How transaction categorisation changes the equation

This is where open banking comes in – but it’s worth being precise about what it does and doesn’t do.

Open banking allows a player to securely connect their bank account to an operator (via a regulated payment provider) and grant read-only access to their transaction data. Under EU rules, access can run continuously, with the player re-authenticating at least every 180 days – a live feed of real financial activity rather than a static document.

But open banking itself only provides the raw data – a feed of transaction records from the player’s bank account. It tells you that money came in, how much, and when. It doesn’t tell you what that money is. A €2,400 credit on the 25th of the month could be a salary, a dividend, a PGB payment, or a transfer from the player’s savings account. Open banking gives you the transaction; it doesn’t classify it.

That classification – turning raw bank data into structured, categorised income intelligence – is where the payment provider’s technology matters. And it’s where Yaspa has built a genuine differentiator.

Yaspa’s AI transaction categoriser uses machine learning models trained specifically on the financial patterns that matter to iGaming operators. It doesn’t rely on generic banking categories or simple keyword matching. Instead, it analyses each transaction’s counterparty, amount, frequency, and reference data to classify it accurately – salary from an employer, a PGB payment from the SVB, a savings transfer, a dividend from a company bearing the player’s name – and applies the correct treatment to each.

This means the exclusion rules the KSA requires aren’t applied by a compliance analyst interpreting a document. They’re applied programmatically, by a categoriser that has been trained to distinguish qualifying income from everything that must be excluded – consistently, at scale, for every player. Without the manual analysis, it’s a more private process, it’s more accurate, and it’s more timely, reflecting a player situation now, not last week or last year.

How Yaspa handles income exclusions in practice

Crucially, none of this requires a separate compliance tool or an additional step in the player journey. Yaspa’s Intelligent Payments platform handles income categorisation and exclusions as part of the deposit itself. When a player makes a payment via Yaspa, they connect their bank, the deposit processes, and the financial intelligence is generated in the background – all in a single flow. The player experiences a payment; the operator receives a fully categorised, audit-ready affordability assessment built to the KSA’s exclusion rules and an automated, audit-ready process that applies the KSA’s exclusion rules consistently.

The AI transaction categoriser doesn’t just identify income – it separates qualifying income from everything the KSA says must be excluded. Here’s what that looks like in practice:

• Automatic income classification. Yaspa identifies and categorises income across all standard personal account types – salary, pension, rent and others – with 95%+ accuracy on known merchants, with anything ambiguous flagged for operator review rather than silently included. Each income stream is classified separately, so the operator can see exactly what qualifies.
• Excluded income is excluded by default. Borrowed money, earmarked income (PGB, housing allowance, child support, tax credits), and business expense reimbursements are identified and excluded from the qualifying income calculation. The operator doesn’t need to spot these manually – the categoriser handles it.
• Net income, not gross. For salaried players, because Yaspa measures inflows as received – post-tax, post-deductions – the risk of miscounting gross income as net income is eliminated. What appears in the bank account is what the player actually received after tax. This is inherently more accurate than interpreting a tax return or payslip.
• Liquid asset receipts flagged separately. Savings transfers, one-off gifts, gambling withdrawals, and refunds are classified as liquid asset movements, not income. Yaspa also provides a separate metric on credit transactions not classified as income, giving operators a clear audit trail for why specific inflows were excluded.
• Non-liquid assets can’t enter the picture. Home equity, business equity, and other non-liquid assets don’t appear in bank transaction data – so they can’t accidentally be included in the calculation. This is a structural advantage of bank-data-based assessment over document review, where an operator reviewing a tax return might see (and incorrectly include) Box 3 asset values.
• Self-employed income handled accurately. For players with business accounts, Yaspa measures personal account inflows only – what actually reaches the player’s personal bank account after business expenses and tax. Where a player operates primarily through a business account, Yaspa flags this to the operator for review, rather than guessing at net income.
• Pan-operator gambling spend included. The calculation isn’t just about income – it’s about income relative to gambling spend. Yaspa’s bank feed analysis captures gambling transactions across all operators visible in the connected account(s), giving the operator a true gambling-to-income ratio that includes activity beyond their own platform.

Every assessment is timestamped and audit-ready, with the full data trail – consent event, transaction data, income categorisation, exclusions applied, and affordability output – retained as a dated record. When the KSA asks to see how a net deposit limit was calculated, the supporting documentation is already there.

Why this matters now

The KSA’s duty of care guidance isn’t a consultation document. It’s the standard operators are being assessed against today – and the standard that will determine whether licences are renewed when the first wave expires in October 2026.

The operators who were fined in 2025 weren’t penalised for not having a process. They were penalised for having a process that didn’t work well enough. Income calculation errors – counting gross instead of net, including earmarked income, miscounting self-employed earnings – are exactly the kind of failures the KSA is looking for.

For operators still using manual document review, the question isn’t whether errors will happen. It’s how many, and when the KSA will find them.

Yaspa’s Intelligent Payments platform replaces that risk with a consistent, automated, audit-ready process that applies the KSA’s exclusion rules to every player, every time. No manual interpretation errors. No friction. No additional steps.

To see how Yaspa handles income categorisation and exclusions for the Dutch market, talk to one of our experts.

This is the second in a three-part series. Read part one: Evidence-based income verification: how open banking meets the KSA’s new standard. Part three – covering real-time enforcement and audit-ready documentation – is coming soon. Sign up to our newsletter at the foot of this page to ensure you don’t miss the very latest updates. 

Yaspa is an FCA-authorised open banking payment provider, operating across Europe. Our Intelligent Payments platform combines instant Pay by Bank deposits with AI-powered financial intelligence for iGaming operators. Learn more about Intelligent Payments.