Compliance PPTC 190
Validation Checks by Instafill.ai
1
Applicant age eligibility (16+ at time of application)
Validates that the applicant’s date of birth indicates they are at least 16 years old on the application signature date (or submission date, depending on system rules). This is required because this form is explicitly for applicants 16 years of age or over; under-16 applicants must use a different form. If the applicant is under 16, the submission should be rejected with instructions to use the child application form.
2
Date field format and validity (YYYY-MM-DD / YYYY-MM / unknown)
Checks that all date fields follow the required format: YYYY-MM-DD for full dates (e.g., DOB, issue/expiry dates, signatures, travel dates) and YYYY-MM for address history periods, and that the values represent real calendar dates. For “Anticipated date of travel,” the system must also allow the explicit “Unknown” option and prevent partial/invalid combinations (e.g., month without day if not permitted). If any date is malformed or impossible (e.g., 2025-02-30), the application should be flagged for correction before processing.
3
Required personal information completeness (Section 1 core fields)
Ensures mandatory applicant fields are present: surname, given name(s), UCI (if required by program rules), place of birth (city and country/territory), date of birth, sex selection, current home address, and email address (explicitly marked required). Completeness is critical for identity determination and for contacting the applicant to resolve issues. If any required field is missing, the submission should be blocked or routed to an “incomplete application” queue with a clear list of missing items.
4
UCI format validation (8 or 10 digits)
Validates that the UCI/Client ID contains only digits and is exactly 8 or 10 digits long, as specified in the instructions. This prevents mismatches and failed lookups against IRCC records. If the UCI is present but not in the correct format, the system should reject the value and request correction (or allow blank only if the business rules permit).
5
Name character set and capitalization/printability rules
Checks that name fields (requested surname/given names, former surnames, parent surname at birth, references, guarantor) contain acceptable characters (letters plus limited punctuation such as hyphen/apostrophe) and are not filled with numerals or symbols. The form instructs applicants to type/print in capital letters; systems should normalize case for storage while ensuring the entered content is legible and not obviously invalid (e.g., 'AAAA', '1234'). If invalid characters or clearly non-name content is detected, the application should be flagged for manual review or returned for correction.
6
Former surnames requirement when different from requested surname
Validates that the “All former surnames” field is completed when the applicant indicates or provides evidence of prior names (e.g., identity documents in Section 6 show a different surname) or when the requested surname differs from immigration status name (if captured in the system). Declaring former surnames is important for identity verification and record linkage. If a mismatch is detected and former surnames are blank, the submission should be flagged and the applicant asked to provide former surnames or supporting name-change documentation.
7
Sex selection is exactly one of F/M/X and consistent with status document when required
Ensures the sex field has exactly one selection (F, M, or X) and is not left blank. The instructions note additional requirements if the sex requested does not match the immigration status document; if the system captures the status document sex, it should detect mismatches and require the additional supporting steps/notes per program policy. If sex is missing or multiple values are selected, the application should be rejected as incomplete; if inconsistent, it should be flagged for additional documentation.
8
Address completeness and postal/ZIP code format (Canada vs non-Canada)
Validates that current home address includes number, street, city, province/territory/state, and postal/ZIP code, and that the postal/ZIP code matches the country context (e.g., Canadian postal code pattern A1A 1A1 when province/territory is Canadian). For address history and references, ensures country is provided and postal/ZIP code is present and plausible for that country (at minimum non-empty and within length constraints). If address components are missing or postal codes are invalid for the selected country, the application should be returned for correction to avoid delivery and verification failures.
9
Email and telephone number format validation
Checks that the applicant email (required) is syntactically valid (e.g., local@domain) and that telephone numbers for applicant, guarantor, references, and emergency contact (if provided) contain valid digits and allowable separators, with appropriate length (e.g., 10 digits for North America or E.164-compatible validation if international). Reliable contact details are essential for resolving issues and for reference/guarantor verification. If the required email is missing/invalid or phone numbers are clearly invalid, the submission should be blocked or flagged for correction.
10
Applicant signature and signature date presence and recency (within last 12 months)
Validates that the applicant has signed within the signature box and provided a signature date in YYYY-MM-DD, and that the signature date is not in the future. The checklist states the application must be completed and signed within the last twelve months; the system should compare the signature date to the received/submission date. If unsigned, undated, future-dated, or older than 12 months, the application should be rejected as not meeting submission requirements.
11
Guarantor mandatory fields completed by guarantor (bold fields) and known-for duration >= 6 months
Ensures the guarantor section includes the guarantor signature, date, signed-at location (city and province/territory), and the “I have known the applicant for (number of months)” field, and that the months value is numeric and at least 6. This is critical because guarantor attestation is a core identity control and the form explicitly requires a minimum relationship duration. If any mandatory guarantor fields are missing or months < 6, the application should be rejected or routed to request a new guarantor/statutory declaration in lieu of guarantor.
12
Proof of immigration status document details and expiry logic
Validates that exactly one acceptable immigration status document type is selected/provided and that the immigration status document number and date of issue are present and properly formatted. If an expiry date is applicable, it must be provided and must be on/after the issue date; if the document is required to be valid, expiry must be in the future on the submission date. If document details are missing, inconsistent, or indicate an expired/invalid status document, the application should be flagged as ineligible/incomplete pending updated proof.
13
Previous Canadian travel document logic (Yes/No branching and required details)
If the applicant answers “Yes” to having a previous Canadian travel document, validates that the document number and date of issue are provided and correctly formatted, and that any required enclosure/related declaration is indicated when applicable (e.g., lost/stolen/inaccessible requires PPTC 203 per instructions). This prevents duplicate valid documents and ensures proper handling of replacements. If “Yes” is selected but details are missing, the submission should be rejected as incomplete; if replacement conditions are implied but PPTC 203 is not included, the case should be flagged for follow-up.
14
Foreign travel document possession and explanation requirement
Validates the Section 5 question about having any valid travel document/passport from any country other than Canada: if “Yes,” the system should require confirmation that the original is enclosed; if “No longer in possession,” an explanation must be provided. This is important for entitlement assessment and to prevent misuse of multiple travel documents. If the applicant indicates a foreign document exists but provides neither enclosure confirmation nor a reason for non-possession, the application should be flagged as incomplete.
15
Travel history entries consistency (date left <= date returned; country/reason required)
For each declared trip since entry to Canada, validates that country and reason are provided and that the date left is not after the date returned. It also checks that trip dates are not in the future relative to the application signature date (unless program rules allow future planned travel to be listed separately). If any trip entry is missing required fields or has illogical dates, the application should be returned for correction or flagged for manual review.
16
Identity documents section requirements (at least one ID; not same as immigration status; expiry and name present)
Ensures at least one identity document is listed in Section 6, with type, document number, and the applicant name as it appears on the document; if an expiry date applies, it must be validly formatted and not earlier than the issue/validity context (and ideally not expired at submission, per policy). It also enforces the rule that identity documents must not be the same document used as proof of immigration status in Section 3. If no identity document is provided, or if the only ID duplicates the status document, the application should be rejected as not meeting identity support requirements.
17
References eligibility and uniqueness (2 non-relatives, not guarantor, 18+, known >= 6 months)
Validates that exactly two references are provided, each with required contact details (name, address, at least one phone or email per operational rules), and that neither reference is the guarantor and neither is a relative (as declared by relationship field). It also checks that “has known me for” is numeric and at least 6 months, and that the two references are not duplicates of each other (same name/contact). If references fail eligibility or are incomplete, the application should be flagged and the applicant required to provide acceptable references.