Registry entry

Serbia — Vehicle Registration Application (Registracioni list za motorno-priključno vozilo, Obrazac 1)

The Ministry of Interior's (Ministarstvo unutrašnjih poslova, MUP) "Registracioni list za motorno-priključno vozilo" (Registration sheet for a motor/trailer vehicle, Obrazac 1 / Form No. 1), the single national form on which a vehicle's owner (or, for co-owned vehicles, a co-owner acting with the others' consent) applies for registration in Serbia's unified vehicle register, opening Serbia's DMV vertical (4 of 6), following Business Formation (GOV-2725, 48th jurisdiction), Visa (GOV-2760), and Taxes (GOV-2767). Per the Rulebook's own Article 5, this single form and its coded fields are used across every stage of a vehicle's registration lifecycle — not only first registration, but also issuance of a registration sticker, temporary registration, a change of plates/permit/sticker, and deregistration — with the applicable set of fields keyed off the form's own 'VRSTA POSTUPKA' (type of procedure) code (0-7). Published directly by MUP (mup.gov.rs) as the printed annex to the consolidated 'Pravilnik o registraciji motornih i priključnih vozila' (Rulebook on registration of motor and trailer vehicles), fetched directly and unauthenticated (HTTP 200, application/pdf, 2,018,355 bytes, sha256: 6d41e2f39d056f9ce8651104e83c0965c64eed53ece983e326aeb4b80939a965). This is a flat, non-AcroForm 92-page consolidated legal text (confirmed via pdfjs-dist@3: zero Widget annotations across every page), with Obrazac 1 printed on pages 37-39 as a plain caption-and-blank-line layout (no boxes, checkboxes, or table rulings survive in the PDF's own text/graphics layers — confirmed by rendering pages 37-39 to PNG via pdfjs-dist + node-canvas). Every field/label/code modeled here is read directly from Obrazac 1's own printed layout, cross-checked word-for-word against the Rulebook's own Article 4 (defining the EU-style vehicle codes J/D.1-D.3/E/F.1/G/K/P.1-P.3/Q/S.1-S.2/P5/L/R) and Article 5 (which legally itemizes, numbered 1-14, everything the form contains). This schema is scoped to Article 5's items 1 (vehicle data), the technical-inspection data transcribed onto the form, and items on the form's second side covering procedure type, owner/user/representative data, permit-sticker-plate data, insurance data, and the change-of-plates/change-of-permit/change-of-sticker/deregistration blocks (each gated on the matching VRSTA POSTUPKA code, since the Rulebook's own text ties each block to a specific procedure code). Article 5's own item 3 ('podatke o nazivu organa koji odlučuje o zahtevu' — data on the name of the authority deciding on the request: the police administration/station or the authorized legal entity handling sticker issuance, its registration number, and its authorization number/date) and item 2 ('datum prijema zahteva' — date the request was received) are excluded as office-intake/deciding-authority data, not applicant-facing content, consistent with this registry's established convention for the same class of content (e.g. co/runt's 'Organismo de Tránsito' box, rs/mfa's consular-only column). Article 5's items 13 ('odluku o zahtevu' — the decision on the request: certificate number/date, dates of collection of the certificate/sticker/plates and of the permit, each with an owner/representative signature line) and 14 ('podatke o ovlašćenom licu koje je obradilo zahtev' — the processing officer's own surname/first name/JMBG/signature) are likewise excluded as the deciding authority's own record of its decision and the processing officer's own identity, not applicant-submitted data. This v1.0.0 models 64 fields[] plus 6 documents[] entries drawn from Article 5's own list of mandatory attachments (technical-soundness certificate, mandatory third-party motor-vehicle liability insurance policy, proof of payment of the prescribed registration fee, proof of settled customs/tax duties for the vehicle, proof of ownership/origin of the vehicle, and proof of the owner's identity). GovSchema is an independent, non-profit standards body and is not affiliated with, endorsed by, or operated by the Government of Serbia or the Ministry of Interior.

Registry entry

rs/mup/registracioni-list-za-motorno-prikljucno-vozilo

Jurisdiction
Serbia · national
Version
1.0.0
Verification
draft

Authoritative source Ministry of Interior, "Pravilnik o registraciji motornih i priključnih vozila" (consolidated text), Obrazac 1 — "Registracioni list za motorno-priključno vozilo" (pages 37-39 of 92)

Machine access

Registry catalog
registry/index.jsonone record per schema id

Field reference

64 fields, read from the published schema.json, with names, types, requiredness, and validation as the document states them. The live government form remains the authoritative source.

Fields

  • vehicleType string required

    The vehicle's type/category. Printed as a blank line with no options text, so modeled as free text rather than an invented enum.

  • vehicleBrand string required

    The vehicle's make/brand.

  • vehicleTypeVariantVersion string required

    The vehicle's type, variant, and version, printed as one combined blank field.

  • vehicleCommercialDesignationModel string required

    The vehicle's commercial designation (model).

  • chassisNumber string required

    The vehicle's chassis number.

  • maxPermissibleMassKg number required

    The vehicle's maximum permissible mass, in kilograms.

    range: 0–∞
  • massKg number required

    The vehicle's (unladen/kerb) mass, in kilograms.

    range: 0–∞
  • homologationMark string required

    The vehicle's homologation mark.

  • engineDisplacementCm3 integer required

    The engine's working displacement, in cubic centimeters.

    range: 0–∞
  • enginePowerKw number required

    The engine's power, in kilowatts.

    range: 0–∞
  • fuelOrDriveType string required

    The vehicle's fuel type or drive type. Printed as a blank line with no options text, so modeled as free text rather than an invented enum.

  • powerToMassRatioKwPerKg number optional

    The vehicle's power-to-mass ratio, in kW/kg. The form's own label states this applies only to motorcycles, so left optional for other vehicle types.

    range: 0–∞
  • seatingCapacityIncludingDriver integer required

    The number of seating places, including the driver's seat.

    range: 1–∞
  • standingCapacity integer optional

    The number of standing places, applicable mainly to buses/minibuses; left optional since it does not apply to every vehicle type (e.g. a passenger car).

    range: 0–∞
  • engineNumber string required

    The vehicle's engine number.

  • numberOfAxles integer required

    The vehicle's number of axles.

    range: 1–∞
  • vehicleColor string required

    The vehicle's color.

  • yearOfProduction integer required

    The vehicle's year of production, listed in Article 4 of the Rulebook alongside the coded vehicle-data items even though it carries no EU-style letter code of its own.

    range: 1900–2100
  • bodyworkShape string required

    The vehicle's bodywork shape.

  • loadCapacityKg number optional

    The vehicle's rated load capacity, in kilograms, where applicable (e.g. a cargo vehicle); left optional since it does not apply to every vehicle type.

    range: 0–∞
  • technicalInspectionBodyNameAndSeat string required

    The name and registered seat of the legal entity authorized to perform the vehicle's technical inspection.

  • technicalInspectionBodyCode string required

    The technical-inspection body's own code.

  • technicalInspectionBodyIdNumber string required

    The technical-inspection body's identification number.

  • vehicleTechnicallySound boolean required

    The technical-inspection body's statement of the vehicle's technical soundness. Printed as a fixed heading rather than a labeled blank line; Article 5's own item 2 describes this as a 'konstatacija o tehničkoj ispravnosti vozila' (statement of the vehicle's technical soundness), so modeled as a boolean rather than free text.

  • technicalInspectionDate date required

    The date the technical inspection was performed.

  • technicalInspectionController string required

    The name of the controller/inspector who performed the technical inspection.

  • technicalInspectionNote string optional

    A free-text note on the technical inspection. Printed with no explicit yes/no gate ahead of it, so left optional.

  • procedureType enum required

    The type of procedure being requested on this registration sheet. This single form is used across every stage of a vehicle's registration lifecycle; downstream fields in this document are gated on this selection per the Rulebook's own Article 5 item-by-item description.

    enum: 8 values
  • ownerSurnameOrName string required

    The vehicle owner's surname (for a natural person) or full legal name (for a legal entity).

    classification: pii
  • ownerFirstName string optional

    The vehicle owner's first name, applicable only when the owner is a natural person; left blank when ownerSurnameOrName is a legal entity's name.

    classification: pii
  • ownerResidenceOrSeatAddress string required

    The vehicle owner's residence address (for a natural person) or registered seat address (for a legal entity).

    classification: pii
  • ownerJmbgOrMb string required

    The vehicle owner's unique master citizen number (JMBG, 13 digits, for a natural person) or company registration number (MB, for a legal entity).

    classification: sensitive-pii
  • userSurnameOrName string optional

    The vehicle user's surname or full legal name, when the vehicle's user differs from its owner. Printed with no explicit yes/no gate ahead of this block, so left optional.

    classification: pii
  • userFirstName string optional

    The vehicle user's first name, applicable only when the user is a natural person.

    classification: pii
  • userResidenceOrSeatAddress string optional

    The vehicle user's residence or registered seat address.

    classification: pii
  • userJmbgOrMb string optional

    The vehicle user's JMBG or MB.

    classification: sensitive-pii
  • representativeSurname string optional

    The surname of the representative acting on the owner's behalf, when the request is submitted through a representative. Printed with no explicit yes/no gate ahead of this block, so left optional.

    classification: pii
  • representativeFirstName string optional

    The first name of the representative acting on the owner's behalf.

    classification: pii
  • representationBasis string optional

    The basis of the representative's authority to act (e.g. a power of attorney's number and date of certification).

  • registrationMark string optional

    The vehicle's registration mark (license plate), not applicable to a vehicle that has not yet been assigned one (e.g. a first-time registration).

  • dateOfFirstRegistration date optional

    The vehicle's date of first registration, not applicable to a vehicle being registered for the first time on this same request.

  • dateOfIssue date required

    The date of issue of the traffic permit/temporary-registration certificate/registration sticker.

  • permitRegistrationNumber string required

    The registration number of the traffic permit.

  • permitSerialNumber string required

    The serial number of the traffic permit.

  • stickerControlNumber string required

    The control number of the registration sticker.

  • stickerValidUntil date required

    The registration sticker's validity (expiry) date.

  • registrationValidUntil date required

    The registration's validity date — per the Rulebook's own Article 4/10, the date the registration plates are next due to be replaced.

  • insuranceCompanyName string required

    The name of the insurance company that issued the vehicle's mandatory liability insurance policy.

  • insuranceCompanyRegistrationNumber string required

    The insurance company's own registration number (MB).

  • insurancePolicyNumber string required

    The vehicle's insurance policy number.

  • insuranceValidUntil date required

    The insurance policy's validity (expiry) date.

  • plateChangeReason string optional

    The reason for the registration-plate change, required only when the requested procedure is a change of plates.

  • previousRegistrationMark string optional

    The vehicle's previous registration mark, required only for a plate-change request.

  • newRegistrationMark string optional

    The vehicle's newly assigned registration mark, required only for a plate-change request.

  • plateChangeDate date optional

    The date of the plate change, required only for a plate-change request.

  • permitChangeReason string optional

    The reason for the traffic-permit change, required only when the requested procedure is a change of the traffic permit.

  • permitChangeSerialNumber string optional

    The serial number of the newly issued traffic permit, required only for a permit-change request.

  • permitChangeDateOfIssue date optional

    The date of issue of the newly issued traffic permit, required only for a permit-change request.

  • stickerChangeReason string optional

    The reason for the registration-sticker change, required only when the requested procedure is a change of the registration sticker.

  • stickerChangeDateOfIssueAndControlNumber string optional

    The date of issue and control number of the newly issued registration sticker, printed as one combined field and required only for a sticker-change request.

  • stickerChangeValidUntil date optional

    The validity (expiry) date of the newly issued registration sticker, required only for a sticker-change request.

  • deregistrationReason string optional

    The reason for deregistering the vehicle, required only when the requested procedure is deregistration.

  • deregistrationDate date optional

    The date of deregistration, required only for a deregistration request.

  • plateProcedureUponDeregistration string optional

    What is done with the registration plates upon deregistration (e.g. surrendered, retained under a personalized-plate scheme), required only for a deregistration request.

Verification record

This file is the source-review record for this document version, per the manual-source-review-v1 practice.

Current claim

  • status: draft
  • verification.method: manual-source-review-v1
  • verification.lastVerifiedAt: 2026-07-13
  • maturity.level: structural-reference

This is GovSchema Standard Research cycle GOV-2774, opening Serbia's DMV vertical (4 of 6), following Business Formation (rs/apr/jrpps-pr-sole-proprietor-registration, GOV-2725, 48th jurisdiction), Visa (rs/mfa/visa-application, GOV-2760), and Taxes (rs/purs/pp-gpdg-godisnji-porez-na-dohodak-gradjana, GOV-2767).

Duplicate-concurrent-run check

Checked git branch -a | grep -i rs-mup and git log --all --oneline | grep -i "rs/mup" before starting — neither found an existing rs/mup branch, commit, or PR, so no reconciliation was needed this cycle.

Source verification — independently re-fetched, not trusted from the task brief alone

  • PDF source: the MUP-hosted consolidated text of the "Pravilnik o registraciji motornih i priključnih vozila" (Rulebook on registration of motor and trailer vehicles): https://www.mup.gov.rs/wps/wcm/connect/44c46b7a-3229-4e6f-a6ea-01d518ffb87b/pdf-lat-Правилник+о+регистрацији+моторних+и+прикључних+возила.pdf?MOD=AJPERES&CVID=og9ft-Z — fetched via curl -sL, both with the literal Cyrillic filename and with it percent-encoded (both resolve to the same document; the percent-encoded form is what is recorded in source.url since ajv's uri format keyword rejects literal non-ASCII characters):
    • HTTP 200, Content-Type: application/pdf, 2,018,355 bytes.
    • sha256: 6d41e2f39d056f9ce8651104e83c0965c64eed53ece983e326aeb4b80939a965 (computed via sha256sum), reproduced identically across three separate fetches (two via the percent-encoded URL, one via the literal-Cyrillic URL).
    • Domain mup.gov.rs (Ministry of Interior) is the correct, official first-party agency for Serbian vehicle registration.

PDF structure, independently confirmed via pdfjs-dist

  • 92 pages. Confirmed via pdfjs-dist@3 (legacy build): page.getAnnotations({intent: "display"}) returned 0 Widget-subtype annotations on every page checked — a flat, non-AcroForm consolidated legal text, not a fillable PDF.
  • Located Obrazac 1 by scanning getTextContent() across all 92 pages for "Obrazac 1"/"REGISTRACIONI LIST" — found on pages 37-39 (page 40 begins "Obrazac 2 SAOBRAĆAJNA DOZVOLA", confirming the annex's own boundary).
  • Extracted the full x/y-positioned text layer for pages 37-39 (every getTextContent() item's string, x, and y), then rendered pages 37-39 to PNG via pdfjs-dist@3's legacy build + node-canvas (standardFontDataUrl pointed at the bundled standard_fonts/ directory), and visually cross-checked the render against the positioned-text transcript. Both independently confirm: the annex is a plain caption-and-blank-line layout — every field is a label followed by a colon and a blank line/space to fill in by hand or typewriter; there are no boxes, checkboxes, or table rulings in the PDF's own content stream (unlike, e.g., co/runt's spreadsheet-derived form). The task brief's description of "procedure-type checkboxes" did not hold up under this direct re-derivation — VRSTA POSTUPKA (type of procedure) is a single blank line with a parenthetical numeric legend (0-7) printed immediately below it, not a checkbox row, so it is modeled as one enum field (procedureType) rather than independent booleans or an exclusivityGroups entry — consistent with this registry's own precedent for the same class of single-choice printed field (e.g. co/runt's tramiteType, an 18-value enum for an equivalent multi-procedure form).
  • Cross-checked every EU-style vehicle code (J, D.1-D.3, E, F.1, G, K, P.1-P.3, Q, S.1-S.2, P5, L, R) against the Rulebook's own Article 4 (page 4 of the PDF, which lists the codes in the same order they appear on Obrazac 1) and Article 10 (page 10, which repeats and further defines several codes, including confirming H — "važenje registracije" — is defined as "the date when the registration plates are replaced"). Every code's meaning matches exactly between Obrazac 1's own printed labels and the Rulebook's own defining articles.
  • Cross-checked the form's full content against the Rulebook's own Article 5, which legally itemizes, numbered 1-14, everything Obrazac 1 contains — this is the primary grounding for every scoping decision below, and is a stronger source than this registry's usual "visually confirm the office-only column" precedent (e.g. rs/mfa's consular column, jo/mfa's "For Official Use" sidebar), since the distinction here is stated by the legal text itself rather than inferred from layout alone.

Scope: what is modeled as fields[], and what is excluded

Included (Article 5's items 1, 2, and — on the form's own "second page" — items 1 and 4-12):

  • Vehicle data (item 1): the 17 EU-coded fields plus yearOfProduction, bodyworkShape, and loadCapacityKg (Article 5 lists these three alongside the coded items even though none carries its own EU-style letter code).
  • Technical-inspection data (item 2): the inspecting body's name/seat/ code/ID number, its vehicleTechnicallySound statement (Article 5's own phrase: "konstatacija o tehničkoj ispravnosti vozila"), inspection date, controller, and note.
  • Procedure type (second-page item 1): procedureType, an 8-value enum.
  • Owner data (item 4), user data (item 5, left fully optional since the form prints no yes/no gate ahead of this block and a vehicle's user frequently is its owner), representative data (item 6, likewise left optional).
  • Permit/temporary-registration-certificate/sticker data (item 7) and insurance data (item 8).
  • Change-of-plates (item 9), change-of-permit (item 10), change-of-sticker (item 11), and deregistration (item 12) data — each gated via requiredWhen on the matching procedureType value (change_of_plates, change_of_registration_certificate, change_of_registration_sticker, deregistration respectively). This gating is grounded directly in the Rulebook's own Article 5, which describes this single form as covering every one of these procedures via the same VRSTA POSTUPKA code — not an invented gate. Per this registry's documented requiredWhen gotcha, every one of these gates uses an explicit equals check against a real enum value, never notEquals "" against an optional field.

Excluded (Article 5's second-page items 2, 3, 13, and 14 — the deciding authority's own intake/decision/processing-officer data, not applicant-submitted content):

  • Item 2, "datum prijema zahteva" (date the request was received) — an office-intake timestamp.
  • Item 3, "podatke o nazivu organa koji odlučuje o zahtevu" (data on the name of the authority deciding on the request): the police administration (PU) and station (PS), or the authorized legal entity handling sticker issuance, together with its seat, registration number, and authorization number/date. This is the direct analogue of co/runt's excluded "Organismo de Tránsito" identification box and rs/mfa's excluded consular-only column, except here the exclusion is grounded in the Rulebook's own explicit, separately numbered legal item rather than inferred from a printed box boundary.
  • Item 13, "odluku o zahtevu" (the decision on the request): the certificate number/date, the dates the certificate/sticker/plates and the permit were collected, and two owner/representative signature lines acknowledging that collection. Excluded as the deciding authority's own transactional record of a later collection event, not data the applicant supplies when submitting the request.
  • Item 14, "podatke o ovlašćenom licu koje je obradilo zahtev" (data on the authorized person who processed the request): the processing officer's own surname, first name, JMBG, and signature.

Documents

documents[] models the six mandatory attachments Article 5's own closing paragraph lists ("Uz zahtev iz stava 1. ovog člana prilaže se: ...", items 1-6): the technical-soundness certificate (with the source's own "ne sme biti stariji od 30 dana" / not older than 30 days freshness requirement modeled via freshness.issuedWithin: P30D), the mandatory third-party liability insurance policy, proof of settled customs/tax duties, proof of payment of the registration fee, proof of ownership/ origin (gated via requiredWhen on procedureType equals registration_in_unified_registry, since the source's own condition — "ako se vozilo prvi put upisuje u registar ili prilikom promene vlasništva", i.e. first registration or a change of ownership — maps onto that single procedure code; the form's own VRSTA POSTUPKA legend has no separate code for a change of ownership), and proof of the owner's identity.

One disclosed judgment call: the other five documents (all but the ownership-proof one) are modeled with an unconditional required: true, matching Article 5's own attachment list, which is stated generally for "the request referred to in paragraph 1" without narrowing to a specific VRSTA POSTUPKA code. In practice this may over-require some documents for narrower procedures (e.g. a technical-soundness certificate for a pure deregistration); a future review with direct access to MUP's own per-procedure checklists (if published) should reconsider narrowing these via requiredWhen gates on procedureType.

Field-count reconciliation against the task brief's estimate

The task brief estimated "~55-60 discrete fields." This document models 64 fields. The difference is fully accounted for by the four procedure-specific blocks (change of plates/permit/sticker, deregistration — 13 fields together), which the brief's own field-code list did not anticipate but which Article 5 confirms are genuinely part of this same form (each keyed to its own VRSTA POSTUPKA code), and are disclosed here rather than silently trimmed to hit the estimate.

Conformance fixtures

Two valid scenarios (0 errors each):

  • valid-first-registration-owner-only.jsonprocedureType: registration_in_unified_registry, a natural-person owner with no separate user/representative, proofOfOwnershipOrOrigin provided.
  • valid-sticker-change-with-user-and-representative.jsonprocedureType: change_of_registration_sticker, a legal-entity owner with a separate natural-person user and a representative acting under a power of attorney, exercising the optional user/representative blocks and the sticker-change conditional block; proofOfOwnershipOrOrigin correctly omitted since this procedure code does not require it.

Eight mutation controls, each raising exactly one error:

`` $ node check.mjs schema.json mutation-control-missing-required-field.json ["vehicleBrand: required but missing"] $ node check.mjs schema.json mutation-control-invalid-enum-value.json ["procedureType: value \"unicorn_procedure\" not in enum [...]"] $ node check.mjs schema.json mutation-control-invalid-type-engine-power.json ["enginePowerKw: expected type number, got string (\"110\")"] $ node check.mjs schema.json mutation-control-invalid-date-format.json ["technicalInspectionDate: expected date (YYYY-MM-DD), got \"01/07/2026\""] $ node check.mjs schema.json mutation-control-missing-required-document.json ["document technicalSoundnessCertificate: required but not provided"] $ node check.mjs schema.json mutation-control-missing-conditional-ownership-document.json ["document proofOfOwnershipOrOrigin: required but not provided"] $ node check.mjs schema.json mutation-control-missing-conditional-sticker-change-field.json ["stickerChangeReason: required but missing"] $ node check.mjs schema.json mutation-control-value-below-minimum.json ["massKg: -5 below minimum 0"] ``

check.mjs is a scratch, from-scratch conformance checker (built in /tmp, never committed) that walks fields[]/documents[], required/requiredWhen (evaluating the shared condition grammar), type, and validation (enum/minimum/maximum/minLength/ maxLength/pattern), plus an unknown-field check. All ten fixtures (two valid, eight mutation controls) were run against it; both valid fixtures returned [] and every mutation control returned an array of exactly one error string, matching the results above.

The registry's zero-dependency structural validator and its ajv-based meta-schema validator were both run against the full registry (including this new schema) and pass:

``` $ node tools/validate.mjs 417/417 document(s) passed. 3/3 mapping.json companion(s) passed.

$ node tools/validate-ajv.mjs 417/417 document(s) validated against the meta-schema (ajv 2020-12). 3/3 mapping.json companion(s) validated. ```

Two ajv findings were fixed before this run: (1) source.url's literal Cyrillic filename failed ajv's uri format check, so the URL is recorded percent-encoded (re-fetched and confirmed byte-for-byte identical to the literal-Cyrillic form); (2) the two conditionally-required documents[] entries initially carried a description property, which the v0.3 document $def does not permit (additionalProperties: false) — the explanatory prose was folded into each entry's sourceRef instead.

The scratch pdfjs-dist/canvas install used for PDF extraction and rendering was done in an isolated /tmp scratch directory, never inside tools/ or tools/govschema-client/. Running node tools/validate-ajv.mjs itself required a one-time npm ci --include=dev inside tools/ (its ajv/ajv-formats devDependencies were not yet installed in this worktree) — this is tools/'s own package.json-declared dependency set, not a scratch install, and is the documented workaround for this registry's own "local NODE_ENV=production makes npm ci skip ajv" gotcha.

tools/govschema-client/registry-index.json was regenerated via npm run build-index inside tools/govschema-client/.

Scope and jurisdiction notes

  • Opens Serbia's DMV vertical (4 of 6). Passport and National ID remain open, and both were screened and confirmed dead ends this same cycle (in-person/biometric appointment only, no downloadable current application form) — see CATALOG.md's "Known Gaps & Opportunities" for the disclosed screening record, including a weak voter-registration- abroad candidate at MFA left as thin backlog.
  • jurisdiction.level is national — MUP is Serbia's national interior/ police authority, and vehicle registration is a nationally-uniform procedure (administered locally by police administrations/stations and by authorized private legal entities for sticker issuance, but governed by this single national Rulebook and form).
  • process.type is registration, matching co/runt's and rw/rra's own convention for the equivalent DMV-vertical form type.
  • process.language is sr, matching rs/apr and rs/mfa's own convention for this jurisdiction, since the source is monolingual Serbian (Latin transliteration, per the PDF's own "pdf-lat-" filename prefix).

Re-verification

Per the practice's cadence, nextReviewBy is set to 2027-01-13 (6 months). A future review should prioritize: (1) confirming whether MUP publishes any per-procedure attachment checklist that would let the five currently-unconditional documents[] entries be narrowed with requiredWhen gates; (2) re-screening Serbia's Passport and National ID verticals, both confirmed dead ends this cycle but potentially revisited if a downloadable form is published; (3) the disclosed weak MFA voter- registration-abroad candidate (.doc format, ~10 fields) as thin backlog if no stronger candidate emerges first.

View the raw record (VERIFICATION.md)

Version history

  • 1.0.0 draft latest this page has verification record schema.json

Independent and non-affiliated

GovSchema is an independent, open-source project. This reference is not produced, reviewed, or endorsed by Ministarstvo unutrašnjih poslova (Ministry of Interior) or any government. The authoritative source is always the live government form and its official instructions.