Date of birth in sanctions screening: handle partial dates

Enter only the birth-date detail you know

A customer record may contain only a birth year, while a listed record has a full date, several possible dates or no date. In SanctionsKit New screening, enter the known value for a person. The API uses subject.birthDate. Leave it absent if you do not know it.

A year, month, full date and range convey different facts. Replacing a year with January 1 invents a month and day. That can create a false conflict when a reviewer later compares the person with a source record.

SanctionsKit accepts YYYY, YYYY-MM or a valid YYYY-MM-DD as input. Source evidence keeps original date text and precision, including ranges and uncertainty. Check the input contract before converting an upstream field. You do not need a separate date-normalization service to submit the supported forms.

Send a birth year through the API

The example uses an invented person and synthetic sandbox coverage. Submit it with the authenticated API quickstart. In Production, use verified subject facts and available sources or a versioned package in place of sandbox@1. Include the published policy reference when required.

A known month can be 1984-06; a full date can be 1984-06-18. Omit birthDate when unknown. Do not send an empty string or a source range as the customer's date. Read the returned evidence in the review case: overlapping dates do not always mean exact agreement.

{
  "subject": {
    "name": "Mira Calder",
    "entityType": "person",
    "birthDate": "1984"
  },
  "package": "sandbox@1",
  "retention": "standard"
}

Example: one date is more precise than the other

In this fictional comparison, Mira Calder's verified date is 1984-06-18 and the source gives 1984. The year agrees, but the source does not confirm the month or day. Record agreement at year precision and leave the rest unknown.

A source value of 1984-06 agrees at month precision. A reliable full date of 1985-06-18 conflicts. Check where the source date came from and whether it lists alternatives before relying on the difference. One date comparison is part of the full identity review, not a decision on its own.

Keep ranges and alternative dates visible

'Approximately 1980' is not the same claim as '1980.' A range from 1979 to 1982 permits several years. An overlapping customer date can be consistent with the range without proving identity. Keep the source wording where the reviewer can read it.

Consider relevant alternative dates rather than selecting the one that supports a preferred outcome. Explain the remaining uncertainty. If an upstream system accepts only full dates, retain the source value separately and leave its derived full-date field empty instead of making a date up.

Do not confuse a download date with a legal date

Retrieval time says when SanctionsKit obtained a file. Publication time says when the publisher issued a version, if supplied. A legal effective date concerns the measure itself. A file downloaded today may describe an action that began months earlier.

A website update, HTTP Last-Modified header or workbook date is not automatically the measure's legal date. Some exports lack a reliable publication time. Leave that unknown. The dataset directory and version guide help distinguish data freshness from the authority's history.

Example: three dates in one record

Suppose a fictional file was fetched on September 17, the publisher dated it September 15, and a listed measure began on July 3. Each date answers a different question. The first establishes when the file was obtained; it does not establish when the person was listed or the measure took effect.

A source may also include an end date or historical record. Read the status, applicable period and authority reference before deciding what applies now. Keep relevant source dates and the screening date with the result. An old start date alone does not show that a measure has ended.

Check dates at input and again during review

Check the customer's value before submitting it, then compare the actual source evidence in the case. If verified details need a correction, use the supported flow and review the new screening. Preserve the earlier result with the information known at that time.

• Keep unknown dates empty and preserve the precision that is actually known.
• Validate full dates as real calendar dates instead of accepting impossible values.
• Keep alternative dates, ranges, and uncertainty distinguishable in source evidence.
• Describe a year or month overlap at its shared precision, without claiming full-date agreement.
• Keep retrieval, publisher, and legal effective dates in separately labeled fields.
• Record the comparison and its limits when a date influences a review decision.

Write a note that explains the missing detail

For the first example, write: customer date 1984-06-18; source gives 1984 only; year agrees; month and day unknown; more identity evidence needed. That note explains why the case remains open. 'Dates match' would hide the uncertainty.

Keep only the information your review needs and follow your retention policy. Evidence retention controls how long submitted facts remain available. Plan for later review before deleting data: a future reader cannot retrieve details that the policy has removed.

Frequently asked questions