Verification of Payee only helps if people trust its warnings. If too many honest payments come back as Bijna overeenkomst or Geen overeenkomst, users learn to ignore the signal - which defeats the point. The fix isn't to weaken the check; it's to feed it better input.
Why false positives happen
The scheme matches the name you send against the account holder. Most false positives are formatting differences, not fraud: a missing middle name, initials vs full name, a trading name vs a registered name, accents and transliteration, or extra words like 'Ltd' or 'S.r.l.'.
Better input, fewer false alarms
You can't change how the bank stores the name, but you can control what you send. The closer your input is to the official record, the fewer Bijna overeenkomstes you'll see.
Practical ways to cut them
- 1 Send the most official name you hold - the registered or legal name, not a nickname.
- 2 For businesses, include an organisation identifier (e.g. VAT number) so matching isn't name-only.
- 3 Normalise obvious noise (trim whitespace, consistent casing) but don't strip meaningful parts.
- 4 Capture the verified name returned on a Bijna overeenkomst and reuse it for future payments.
Turn Bijna overeenkomstes into clean data
A Bijna overeenkomst is an opportunity: show the suggested verified name, let the payer confirm, and store that confirmed form. Over time your records converge on the names banks recognise, and your false-positive rate falls. RoxPay returns the verified name and supports organisation-identifier matching, so you can design this loop into your flow.