> ## Documentation Index
> Fetch the complete documentation index at: https://developer.fin.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Individual ID Document Upload

> Best practices and edge cases for uploading individual ID documents through fin.com.

## Image and file requirements

<AccordionGroup>
  <Accordion title="What file formats are accepted?">
    JPG, JPEG, PNG, and PDF. The file must be an original photo, a scan, or a screenshot — and screenshots are only accepted if the country and document type configuration explicitly allows them (most don't by default).
  </Accordion>

  <Accordion title="What's the minimum image quality?">
    Minimum specs:

    * File size at least **100 KB** or resolution at least **300 DPI** (one of the two, not both).
    * Image must be in **color** — black-and-white scans are rejected.
    * All four corners of the document must be visible inside the frame.
    * No foreign objects or graphic elements covering the document.
    * The image must not have been edited with software or converted to PDF after capture.
    * Information on the document must be readable — no blur, glare, or shadows obscuring data.
  </Accordion>

  <Accordion title="What information must be readable on the document?">
    All of the following must be clearly visible and machine-readable:

    * Owner's full name
    * Date of birth
    * Document number
    * Photo of the owner
    * Signature (if the document includes one)
    * MRZ — Machine Readable Zone (the two or three rows of characters at the bottom of passports and many ID cards)
    * Validity data — issue date or expiry/validity period

    If any of these are unreadable, automated text extraction will fail and the document will be flagged for review or rejected.
  </Accordion>
</AccordionGroup>

## Document handling

<AccordionGroup>
  <Accordion title="Which documents need both sides uploaded?">
    As a general rule:

    * **Passports** — usually 1 image (the photo page). Some configurations require the full double-page spread.
    * **ID cards, driver's licenses, residence permits** — both sides required.

    Per-country settings determine the exact requirement, with four possible options: document not allowed, front side only, both sides required, or either side accepted. When both sides are required, you must upload the second side after the first — otherwise the verification step stays incomplete and the user can't be moved forward for review.
  </Accordion>

  <Accordion title="Are digital documents (e-IDs, mobile driver's licenses, etc.) accepted?">
    Generally **no**. Digital documents lack the physical security features (holograms, raised printing, watermarks) that authenticity checks rely on, which makes them easier to forge. Specific countries can be configured to accept digital versions on a case-by-case basis. If you're unsure whether a particular country allows digital documents, check the configuration first.
  </Accordion>

  <Accordion title="Are screenshots accepted?">
    Not by default. Screenshots are rejected outright in most cases. There's a per-country setting that can be enabled if there's a legitimate reason to allow them, but it's off by default. Photos of a screen (as opposed to true screenshots) are also rejected — they're treated separately as suspected tampering.
  </Accordion>

  <Accordion title="Are notarized copies of ID documents accepted?">
    Yes, notarized copies of identity documents are accepted. However, **documents issued in breakaway regions are not accepted by default.**
  </Accordion>

  <Accordion title="What about expired documents?">
    Expired documents are not accepted. As a cautionary measure, the document's expiry date should be at least **one year away** from the date of submission. This avoids the banking partner coming back later asking for a fresh set of documents when the current one expires.
  </Accordion>

  <Accordion title="What languages are supported?">
    Documents in 40+ languages from 220+ countries and territories are processed, including Korean, Japanese, Chinese, Cyrillic, and Semitic scripts. There are two exception groups:

    * **Latin characters only** for: Amharic, Bengali, Burmese, Dari, Dhivehi, Hindi, Khmer (Cambodian), Kinyarwanda, Mongolian, Nepali, and Sinhalese. If a document is submitted in the local script, a notarized Latin translation must be provided.
    * **Available on request, additional cost**: Arabic, Farsi, Urdu, Lao.
  </Accordion>

  <Accordion title="Are Proof of Address documents in a different language accepted?">
    Yes. Proof of Address documents (such as bank statements, utility bills, rental agreements) do not need to be in English. However, if the document is in a different language, it must be accompanied by a **certified English translation** to ensure accurate review.
  </Accordion>
</AccordionGroup>

## Upload guidance

<AccordionGroup>
  <Accordion title="What information needs to accompany each upload?">
    Two pieces of information are mandatory with every document upload: the **document type** (passport, ID card, driver's license, residence permit, etc.) and the **issuing country**. Additional details — document number, issue date, date of birth, place of birth — are optional but recommended; sending them upfront speeds up processing and improves match accuracy.
  </Accordion>

  <Accordion title="How do I indicate which side I'm uploading for a two-sided document?">
    Each side is uploaded as a separate image with a marker indicating whether it's the front or back. For a two-sided document, you must upload both — uploading only the front leaves the verification step incomplete and the user cannot be moved forward for review.
  </Accordion>

  <Accordion title="Should I check for warnings during upload?">
    Yes. Upload responses will surface warnings or errors immediately for the first few attempts on a given document — use this to prompt the user to retry before marking them as ready for review. After several attempts on the same document, warnings stop appearing on the upload response and any issues will only be caught during the full verification check, which is slower and more disruptive for the user.
  </Accordion>
</AccordionGroup>

## Common rejection and warning reasons

<AccordionGroup>
  <Accordion title="What are the common rejection reasons?">
    | Reason                                | What it means                                                                                                                                |
    | ------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- |
    | **Forbidden document**                | The document type or country isn't supported, or isn't acceptable for this verification level.                                               |
    | **Document type or country mismatch** | What was detected in the image doesn't match the document type or country you declared, and the detected type is forbidden by your settings. |
    | **Missing important information**     | Required fields (name, DOB, document number, etc.) couldn't be extracted from the image.                                                     |
    | **No readable data**                  | Nothing recognizable in the image — usually means it's blank, corrupted, or not actually a document.                                         |
    | **Expired document**                  | The document's validity date has passed, and your configuration doesn't allow expired documents.                                             |
    | **Document cropped**                  | Parts of the document are cut off at the edges of the photo.                                                                                 |
    | **No face photo on document**         | The face photo on the document isn't clearly visible.                                                                                        |
    | **Poor selfie quality**               | Face on the selfie isn't clearly visible (when comparing selfie to document).                                                                |
    | **Photo of a screen**                 | The image looks like a photo taken of a screen, not the original document.                                                                   |
    | **Screenshot**                        | The image is a digital screenshot (and screenshots aren't enabled for this country/document).                                                |
    | **Same side uploaded twice**          | The same side of the document was uploaded as both the front and back.                                                                       |
    | **Missing MRZ**                       | The document type sent should have a Machine Readable Zone, but no readable MRZ was found.                                                   |
    | **Missing second side**               | The document type requires both sides; only one was sent.                                                                                    |
    | **Missing double-page spread**        | The full double-page spread is required (typical for some passport configurations); only one page was sent.                                  |
    | **Previously declined image**         | This exact image was uploaded and declined earlier for the same user. A different photo is required.                                         |
  </Accordion>

  <Accordion title="What are the common warnings?">
    Warnings don't block the upload but signal something to keep an eye on:

    | Warning                              | What it means                                                                             |
    | ------------------------------------ | ----------------------------------------------------------------------------------------- |
    | **Bad selfie**                       | Face and document photo aren't both clearly visible on the selfie — user should retake.   |
    | **Borderline readability**           | Information on the document is hard to read — image quality is on the edge of acceptable. |
    | **Inconsistent documents**           | Uploaded photos look like they might not all be of the same document.                     |
    | **Possibly expired**                 | Document appears to be expired but wasn't rejected outright.                              |
    | **Document partially outside frame** | Document doesn't fully fit in the photo frame.                                            |
  </Accordion>
</AccordionGroup>

## Verification outcomes and resubmission

<AccordionGroup>
  <Accordion title="What does a successful verification look like?">
    The user is approved and you receive a positive verification webhook. You can fetch their full data afterwards if you need it for downstream processing.
  </Accordion>

  <Accordion title="What happens when verification fails?">
    Failures come in two flavors, and they mean very different things:

    * **Final rejection** — the user is permanently blocked from this verification and cannot resubmit. This is rare (about 1–2% of cases) and typically means a fake account or forged documents. Block them in your system and direct them to support.
    * **Retry rejection** — the user has fixable issues. They can resubmit only the problematic step (no need to redo the whole flow).
  </Accordion>

  <Accordion title="How do I tell the user what to fix?">
    Each problematic verification step comes with a human-readable comment explaining what went wrong. Show that comment to the user. Example: *"The text on your identity document is not clearly visible. Upload a new photo."* Have them re-upload only the problematic document, mark them as ready for review again, and wait for the next verification result.
  </Accordion>

  <Accordion title="Can a previously approved user be rejected later?">
    Yes. Verification status is not permanent. A user approved today might appear on a sanctions list or blocklist next week, and you'll receive a negative status webhook for that change. Your webhook handler must deal with downgrades, not just upgrades.
  </Accordion>
</AccordionGroup>

## Edge cases and gotchas

<AccordionGroup>
  <Accordion title="The full picture is visible but the edges of the document can't be seen.">
    This is one of the most common upload mistakes. Even though the photo itself is well-framed, if the document's own edges are cut off — corners outside the frame, edges flush against the photo border, or the document extending past what the camera captured — the upload will be rejected. **All four corners of the document must be visible inside the photo**, with a small margin of background around them. Tell users: hold the document so the entire card or page sits inside the frame with space around it.
  </Accordion>

  <Accordion title="What happens if I only upload the front side of a two-sided document?">
    The verification step will not complete. The user cannot be moved forward for review. Always upload the back side after the front for two-sided documents.
  </Accordion>

  <Accordion title="What if the same side gets uploaded twice by accident?">
    The upload will be rejected with a same-side error. Both images will be marked inactive. Re-upload with the correct front and back.
  </Accordion>

  <Accordion title="What happens when I re-upload a document for someone who already has one?">
    Re-uploads merge, they don't replace cleanly. If a document of the same type and country already exists for that user: any new metadata fields you send will **overwrite** the existing values, but the new image is **added alongside** the existing one, not replacing it. If you want to invalidate an old image, you need to mark it inactive explicitly.
  </Accordion>

  <Accordion title="What if the same image was already declined before?">
    You'll get a previously-declined error. Rejected images are remembered per user — they must take a new photo, not re-submit the same file.
  </Accordion>

  <Accordion title="All documents must belong to the same person — what does that mean?">
    If a user uploads a passport, then later uploads a utility bill or a selfie, all of those must match the same person. A passport for John Smith and a driver's license for Jane Doe in the same user profile = inconsistency warning and likely rejection.
  </Accordion>

  <Accordion title="What if the data on my side doesn't match what's on the document?">
    If you've sent user data (name, DOB, etc.) for cross-checking and it disagrees with what's extracted from the document, the user gets flagged with a problematic-data label. Make sure your application lets users edit their data *before* they hit submit, so they can correct typos rather than face rejection.
  </Accordion>

  <Accordion title="What if the detected document differs from what I declared?">
    If the document type or issuing country detected by the verification system doesn't match what you declared during upload, your declared values may be **overwritten** by what was actually detected. If your downstream systems depend on those values, always compare what you sent against what comes back in the response.
  </Accordion>

  <Accordion title="Can users submit notarized translations?">
    Yes — and for the Latin-only language list (see "What languages are supported?" above), notarized translations are required if the document is in the local script.
  </Accordion>

  <Accordion title="What if the document is scratched, stained, or torn?">
    Damaged documents are not accepted. The user needs to obtain a replacement from the issuing authority before they can complete verification.
  </Accordion>
</AccordionGroup>