Skip to main content

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.

Image and file requirements

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).
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.
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.

Document handling

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.
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.
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.
Yes, notarized copies of identity documents are accepted. However, documents issued in breakaway regions are not accepted by default.
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.
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.
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.

Upload guidance

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.
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.
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.

Common rejection and warning reasons

ReasonWhat it means
Forbidden documentThe document type or country isn’t supported, or isn’t acceptable for this verification level.
Document type or country mismatchWhat 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 informationRequired fields (name, DOB, document number, etc.) couldn’t be extracted from the image.
No readable dataNothing recognizable in the image — usually means it’s blank, corrupted, or not actually a document.
Expired documentThe document’s validity date has passed, and your configuration doesn’t allow expired documents.
Document croppedParts of the document are cut off at the edges of the photo.
No face photo on documentThe face photo on the document isn’t clearly visible.
Poor selfie qualityFace on the selfie isn’t clearly visible (when comparing selfie to document).
Photo of a screenThe image looks like a photo taken of a screen, not the original document.
ScreenshotThe image is a digital screenshot (and screenshots aren’t enabled for this country/document).
Same side uploaded twiceThe same side of the document was uploaded as both the front and back.
Missing MRZThe document type sent should have a Machine Readable Zone, but no readable MRZ was found.
Missing second sideThe document type requires both sides; only one was sent.
Missing double-page spreadThe full double-page spread is required (typical for some passport configurations); only one page was sent.
Previously declined imageThis exact image was uploaded and declined earlier for the same user. A different photo is required.
Warnings don’t block the upload but signal something to keep an eye on:
WarningWhat it means
Bad selfieFace and document photo aren’t both clearly visible on the selfie — user should retake.
Borderline readabilityInformation on the document is hard to read — image quality is on the edge of acceptable.
Inconsistent documentsUploaded photos look like they might not all be of the same document.
Possibly expiredDocument appears to be expired but wasn’t rejected outright.
Document partially outside frameDocument doesn’t fully fit in the photo frame.

Verification outcomes and resubmission

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.
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).
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.
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.

Edge cases and gotchas

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.
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.
The upload will be rejected with a same-side error. Both images will be marked inactive. Re-upload with the correct front and back.
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.
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.
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.
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.
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.
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.
Damaged documents are not accepted. The user needs to obtain a replacement from the issuing authority before they can complete verification.