21 entries changed, zero names added: the UN list update that quietly broke your matches

Nothing, if you count names. On 18 August 2026 the Security Council Committee pursuant to resolutions 1267 (1999), 1989 (2011) and 2253 (2015) amended 21 entries on the ISIL (Da'esh) and Al-Qaida Sanctions List, 13 individuals and 8 entities, four days after amending three individuals and one entity on 14 August. No name was added, none was removed, and the Committee's page still states 252 individuals and 89 entities. A feed of new designations reports both days as quiet.

A matcher does not count names. It reads fields, and the fields moved: 6 new alias strings, 4 new dates of birth, 5 address changes, identity-document details on 3 entries, and status text on 15 of the 21 entries amended on 18 August. If your last full screen ran before 14 August, some of your results are now wrong in both directions.

The Committee shows each change as strikethrough and underline in the press release, which reads well and parses badly. The XML list records the same change as a new date in the entry's LAST_DAY_UPDATED field and nothing else; the file does not say which field changed.

The alias change is the one that fails silently. Every other amendment alters the disposition of a candidate you can already see; a missing alias means there is no candidate to dispose of. The date-of-birth change fails the other way round. A rule that auto-dismissed on a 1993 or a 1963 date of birth encoded the list as it stood when the rule was written, and it was defensible on 13 August. It is not defensible today. Addresses move the country weights and the country filters with them. And the status notes cut both ways: five individuals now carry a death note, which analysts read as lower priority although the freeze applies until the Committee delists, while QDi.294 moved from "in custody" to running a business, which is the difference between a historical match and a live counterparty.

We took the amendment to QDi.252 and replayed it through a plain matcher: rapidfuzz 3.14, token_sort_ratio, names upper-cased with accents and punctuation stripped, threshold 0.85. The customer record is "Said Merrikh", which is how a passport or an invoice would carry the new alias SAID DIT MERRIKH ("dit" is French for "known as").

Nothing about the customer or the algorithm changed between the two columns; the list version is the only variable. The ABU HAMZA row is the one we would worry about next. A good-quality alias that is also a very common kunya will now hit customers with no connection to QDi.300, and each of those alerts needs a documented dismissal. And not every new alias matters to a fuzzy matcher: ABD EL ILAH already scored 0.96 against the existing Abd El Illah, so it changes the result only for an exact matcher. Alias updates need to be read, not counted.

The measures in paragraph 1 of resolution 2734 (2024) are a continuing prohibition: no funds or economic resources may be made available to a listed person, on any day. QDi.252 has been on the list since 3 July 2008. A firm that onboarded "Said Merrikh" in 2019 and screened correctly got "no candidate", and would have got the same answer on 17 August 2026, because the list did not carry the alias until the 18th. From that day the firm holds a customer whose name matches a listed person's alias, and a screening record that says otherwise.

The onboarding record proves diligence on the day it was produced and nothing about today. An auditor or a competent authority asks two questions: when did you last screen this customer, and against which list version. The amendments cut both ways, so dispositions made on the old text are stale too: five entries now say the person is dead, two entities lost their Pakistani addresses, and one listed person is documented as released and trading.

For EU firms the same amendments carry an Official Journal date. Commission Implementing Regulation (EU) 2026/1960 of 20 August carried the 13 and 14 August changes into Annex I of Regulation (EC) No 881/2002; Regulation (EU) 2026/1965 of 26 August carried the 18 August changes to "the identifying data for 21 entries". Each was in force two days after adoption, and each repeats the good- and low-quality aliases verbatim, so the same customer crosses the same threshold twice, once against the UN file and once against the EU one.

The list changed on 8 July, 13 August, 14 August and 18 August 2026, and none of those dates added a name. A re-screen calendar driven by new designations would have skipped all four. The file itself implies a different cadence.

1. Pull the XML at least daily and diff it on LAST_DAY_UPDATED per reference number. Keep every pulled file, with its dateGenerated attribute and a hash.
2. Re-screen the book against the delta, not the delta against the book. Six new alias strings against your whole customer base is a cheap query; waiting for the next scheduled full run is not.
3. Re-run every customer whose earlier candidate list touched an amended entry, because date-of-birth, address and status changes alter dispositions you have already made.
4. Keep a monthly full re-screen as the floor. A diff only catches what the diff logic knows about.

One detail from our own pull first, because it shapes every question below. The Committee's XML we downloaded on 4 September (generated 3 September, 23:00 UTC) held 248 individual and 88 entity records against the 252 and 89 stated on the page, and we could not reconcile the difference from public sources. A screening record that cites "the UN list" without naming the file cannot be reproduced either way.

• Versioned snapshots. Which list version did this check use, as a dateGenerated timestamp or a file hash, and can you retrieve that file?
• Alias fields. Are good-quality and low-quality a.k.a.s both indexed, does the result say which alias produced the match, and is it written down whether a low-quality a.k.a. such as ISAAC MUPETA can raise an alert on its own?
• Delta re-runs. When an entry is amended, which customers are re-screened, how soon, and is that automatic or a job someone remembers to run?
• Evidence of the list version used. Does the exported report state the list version, the matched field and the score, so the record can be reproduced later without recalculating it against today's list?
• Date-of-birth and status handling. Are multiple dates of birth, year-only dates and death notes treated as context for an analyst, and never as an automatic dismissal?

This is what a point-in-time record is for. ScreenVeritAI stores every check as a snapshot that names the list version and exports it as a PDF, and continuous monitoring (in Beta) re-runs the book when a list changes rather than when someone reads a press release. Whichever tool you use, the test is the same: whether you can show, for any customer, the exact list the last decision was made against.