Finland Registration of a Foreigner — Request for a Personal Identity Code (Ulkomaalaisen rekisteröinti — Henkilötunnuspyyntö, DVV05.03.00A)

Candidate selection

This session's brief (GOV-2299, "GovSchema Standard Research") targeted Finland's National ID & Civic Documents vertical — globally one of GovSchema's weakest-covered verticals (74% at cycle start) — and named DVV's (Digi- ja väestötietovirasto, the Digital and Population Data Services Agency) form DVV05.03.00A, "The registration information of a foreigner" ("Ulkomaalaisen rekisteröinti"), as the pre-scouted candidate. Finland stood at 2/6 verticals (Visa via fi/migri/residence-permit-employed-person, GOV-2276; Business Formation via fi/prh/start-up-notification-y1, GOV-2292).

Finland's domestic eID/identity-card route (poliisi.fi) was re-confirmed this cycle as online-e-service-or-in-person-only with no downloadable form — not a viable candidate. DVV05.03.00A is the correct, and currently only viable, National ID candidate for Finland.

Source

• English: https://dvv.fi/documents/16079645/39123197/The+registration+information+of+a+foreigner.pdf/d179dd2f-e279-8f32-1f8b-ee1fed610d90/The+registration+information+of+a+foreigner.pdf?t=1753428818556
• Finnish (cross-check only, not the schema's primary source): https://dvv.fi/documents/16079645/42069833/Ulkomaalaisen+rekister%C3%B6inti.pdf/6ca445fd-4f6d-33e9-74be-235e83e50d2c/Ulkomaalaisen+rekister%C3%B6inti.pdf?t=1624338712613
• Both fetched fresh this session with a plain HTTP GET: HTTP 200, 151,115 bytes (English) / 142,376 bytes (Finnish) — both exactly matching a prior scouting pass's byte counts. Both confirmed genuine %PDF-1.7 files (header bytes verified directly) with no login/CAPTCHA/WAF gate.
• Editions: the English specimen prints 06/2025 in its footer; the Finnish specimen prints 04/2025 — same form number, different edition dates, structurally identical (see Extraction below). The English edition is this schema's primary source, consistent with this registry's Migri (fi/migri) precedent of preferring an authority's own English-language edition when one exists.
• Landing pages (fetched fresh this session, used for documents[] provenance): https://dvv.fi/en/foreigner-registration and https://dvv.fi/ulkomaalaisen-rekisterointi.

Extraction technique and a disclosed discrepancy vs. the pre-scouted count

pdfjs-dist v4 (legacy/build/pdf.mjs, installed fresh to a scratch /tmp/fi-dvv-extract directory this session) was used per page via page.getAnnotations() (widget rects, field names, alternativeText tooltips, radioButton/checkBox flags) and page.getTextContent() (printed labels with y-coordinates), on both the English and Finnish specimens independently.

• Page 1: 29 annotations, 28 /Widget-subtype annotations.
• Page 2: 15 annotations, 13 /Widget-subtype annotations.
• Page 3: 10 annotations, 2 /Widget-subtype annotations (a "Save form" and "Print form" button — this page is solely a GDPR privacy statement with 0 applicant-facing fields, excluded from this schema).

Total: 54 annotations, but only 43 are true /Widget-subtype annotations, across 34 unique field names (32 applicant-facing + 2 page-3 buttons). The pre-scouted figure of "54 total widget annotations" counted every annotation on the page (including link annotations, e.g. to Datatilsynet-equivalent privacy-statement pages), not only genuine /Widget subtypes; this cycle's own precise widget-subtype count (43) supersedes that estimate rather than reconciling to it. The 34-unique-name figure matches the pre-scout exactly. Both the English and Finnish specimens produced identical widget counts per page, confirming the two editions are structurally identical despite their different footer dates.

Unlike several prior Nordic specimens in this registry (the DK CPR and Skattestyrelsen forms among them), this specimen's fields are self-documenting without a coordinate cross-reference being strictly necessary: every Tx widget carries its own descriptive alternativeText tooltip quoting the form's own numbered question text verbatim (e.g. field "Text field 1" → alternativeText "1. Surname"), and every one of the form's 7 exclusive-choice radio groups (sex; prior residence in Finland; marital status; contact language; duration of stay; official-decision-by- email preference; the family-members-in-Finland yes/no gate) is confirmed via radioButton: true to be a genuine PDF radio-button parent field, not independent same-named checkboxes sharing an export value (the DK CPR "Medlem af folkekirken" quirk does not recur here). Row y-coordinates were still cross-referenced to confirm each radio option's exportValue maps to its printed label in on-page order (e.g. duration of stay's 4 options, printed top-to-bottom, map to exportValue 0/1/2/3 in that same order) and to pair the 3 independent family-member checkboxes (spouse / children under 18 / parents, checkBox: true, not mutually exclusive — a person can have any combination present) with their adjacent free-text name fields.

Field structure: 32 applicant-facing fields, no merging or splitting

Every one of the 32 applicant-facing widget-groups was modelled 1:1 into a fields[] entry, with two exceptions the source itself visibly nests as follow-ups under two of duration-of-stay's four radio options: temporaryStayEndDate ("End date of temporary stay:") and lessThanYearEndDate ("Less than a year, until:"), each gated via visibleWhen/requiredWhen against durationOfStay. No date-widget splitting was needed (every date on this form is a single text field, unlike Migri's OLE_TY1 split day/month/year widgets), and no field was merged beyond what the source itself already combines (see the next section).

Disclosed modelling decisions

1. postalCodeAndCity is a single field, because the source PDF itself implements postal code and city as one combined text-field widget (item 11), not two — unlike this registry's Danish siblings (dk/cpr, dk/skattestyrelsen), which split them. This schema mirrors the source's own single-field layout rather than introducing a split the form does not have; no separate pattern-validated postal-code field exists on this specimen.
2. maritalStatus is left ungated by any Condition. The form's own instruction text ("We can register your marital status with this form only in these situations. In other cases, marital status is registered with a separate form.") scopes the field to exactly two situations: an applicant under 18 and unmarried, or an applicant unmarried with refugee status or subsidiary protection. No field on the form itself (e.g. a computed age, or a distinct refugee-status flag) exists to gate a Condition against, so — matching this registry's existing precedent for OLE_TY1 section 8 (fi/migri), where an analogous instruction-only scoping constraint had no corresponding gating field — the constraint is disclosed in the field's own description rather than enforced structurally.
3. hasFamilyMembersInFinland and its three dependents model a disclosure/context question, not a full family sub-schema. The source's own instruction text states plainly that family relationships absent from the Population Information System are not registered via this form: "Family relations missing from the Population information System will not be registered with this form. Use the forms 'Notification of marriage outside Finland' and/or 'Notification of child born outside Finland' for notifying family relations." Consistent with that scope, this schema models only a yes/no gate plus three independent presence-flag/name pairs (spouse, children under 18, parents of children under 18) — matching the source's own three checkboxes plus adjacent free-text fields — rather than a repeating per-person sub-schema with date-of-birth, citizenship, etc. for each family member (which the source form does not itself collect for this question).
4. contactLanguage and estoniaOrNordicIdentityNumber are both left ungated against free-text fields (nativeLanguage and countryMovedFrom respectively), since a reliable Condition match (equals/in) against an open-ended free-text value is not possible — matching this registry's existing dk/cpr precedent for the equivalent judgment call. Per this registry's known notEquals-against-an-optional- field bug pattern, no Condition in this schema gates on notEquals against an optional field; every requiredWhen/visibleWhen here is a plain equals check against a boolean or enum field.
5. The physical signature line (item 20, "Signature") carries no fillable AcroForm widget on this specimen, consistent with this registry's dk/cpr and fi/migri precedent for signature lines. It is modelled as an applicantDeclaration attestation documents[] entry quoting the form's own item 19/20 declaration text verbatim, rather than as a fields[] entry.
6. documents[] is sourced partly from outside the PDF itself. The form has no in-PDF attachment checklist (unlike Migri's OLE_TY1 section 11.1); the identity/legal-residence/work-or-study/family-relationship document requirements were instead sourced from DVV's own published foreigner-registration guidance (dvv.fi/en/foreigner-registration, fetched fresh this session), specifically its "Book an appointment for a personal visit" section listing what to bring. proofOfLegalResidence merges two source-listed alternatives (a residence permit card / other proof of legal residence, or an EU right-of-residence registration certificate) into one requirement with two acceptedTypes, since which applies depends on the applicant's own citizenship/status and the source does not name a single universal document. proofOfWorkOrStudy is left required: false (descriptive only) since this form has no single field naming the applicant's chosen grounds for registration (employment, study, family member, or existing residence permit) to gate it against. familyRelationshipCertificates is gated, via requiredWhen against hasFamilyMembersInFinland, since that field does exist on the form.

crossFieldValidation

One rule, movedToAddressNotBeforeMovedToFinland (dateMovedToAddress greaterThanOrEqual dateMovedToFinland), encoding the genuine logical constraint the source's own field ordering implies: an applicant cannot move into their specific Finnish address before entering Finland itself.

Mock conformance test run

Two scenarios were built under conformance/fi/dvv/registration-of-foreigner/1.0.0/ and checked against this schema's required/requiredWhen/visibleWhen/validation/ crossFieldValidation grammar, and its documents[] requiredness explicitly (not just fields[] — a repeatedly-confirmed blind spot in this registry's own history), with a disposable checker script (/tmp/fi-dvv-extract/check_conformance.mjs, not committed — same technique used across this registry's other v1.0.0 cycles):

• application-packet-minimal-required-only.json: a Swedish citizen moving permanently to Helsinki, no prior Finland residence, no family members in Finland. 18 fields collected, 14 correctly not-applicable, 5 documents[] entries checked, 0 errors.
• application-packet-full-coverage-estonian-family.json: a fictional Estonian software developer moving to Tampere for employment, with prior exchange-study residence in Finland, a temporary-stay duration election, an Estonian identity number, a spouse and child already in Finland, and a telephone number. 29 fields collected, 3 correctly not-applicable, 5 documents[] entries checked, 0 errors.
• Six mutation/negative controls, each derived from the minimal scenario with exactly one defect introduced, independently confirmed to raise exactly its own expected error and no other: All six were correctly and individually flagged, confirming the checker script discriminates rather than trivially passing every input, and that documents[] requiredness specifically (mutations 5 and 6) is genuinely exercised, not just asserted.
  1. removing required surname → missing-required.
  2. setting sex to "X" (violates validation.enum) → enum-violation.
  3. setting dateMovedToAddress before dateMovedToFinland → cross-field-violation on movedToAddressNotBeforeMovedToFinland.
  4. setting durationOfStay to temporary_address_at_least_one_year without supplying the now-requiredWhen-triggered temporaryStayEndDate → missing-required.
  5. dropping the required identityDocument from documents[] → missing-required-document.
  6. setting hasFamilyMembersInFinland to true without supplying the now-requiredWhen-triggered familyRelationshipCertificates document → missing-required-document.

The schema was also validated against the GovSchema v0.3 meta-schema with node tools/validate-ajv.mjs (passes standalone and as part of the full registry run, 351/351 documents, 3/3 mapping.json companions) and node tools/validate.mjs (same result). One meta-schema violation was caught and fixed during authoring: two documents[] entries initially carried an undocumented description member (documents only support sourceRef for this kind of free text, not description); the explanatory text was folded into each entry's sourceRef instead.

Scope and jurisdiction notes

This document opens Finland's National ID & Civic Documents vertical (3/6 for Finland; Passport/Driver's License/Taxes remain open). It does not submit the request on the applicant's behalf, and does not replace the in-person appointment DVV (or the State Department of Åland) requires within one month of submitting the form; the live source (dvv.fi) is always authoritative. GovSchema is independent and is not affiliated with, endorsed by, or operated by the Republic of Finland or DVV.