> ## Documentation Index > Fetch the complete documentation index at: https://docs.chmodlab.com/llms.txt > Use this file to discover all available pages before exploring further. # What you can configure > The rules a verification can enforce, and how to think about each of them. Every transaction carries its own rules. When your backend opens a verification it says what should be accepted, and chmod enforces exactly that — nothing is inherited from an account-wide setting, so a strict onboarding check and a lighter re-verification can run side by side. The rules fall into four families. ## Device integrity The SDK observes the device the capture is made on and reports what it finds: whether the phone is rooted or jailbroken, whether it is an emulator, whether developer mode is on, whether the connection goes through a VPN or proxy, whether the GPS position is simulated, and whether the GPS country disagrees with the network country. For each signal you choose what it does to the outcome. Some are strong on their own — a rooted device can feed fake camera frames into the capture, and a simulated GPS position has no innocent explanation. Others are weak and common among genuine users: developer mode, VPNs, a traveller whose GPS and IP countries differ. The defaults reflect that difference, and you can tighten or relax each one. ## Documents You decide which identity documents are acceptable, by country and by type, and whether an expired one is tolerated — per document, so an expired national ID can be fine while a passport must be valid. You can also ask chmod to compare what the document says against what you already hold about the person. Names are compared by similarity, because documents print them uppercase, unaccented and sometimes without a middle name; dates, numbers and countries are compared exactly. Anything you supply becomes a requirement: if it does not match, the verification fails. ## Biometrics The liveness check confirms a real, present person rather than a photo, a video or a mask. You set how confident chmod must be before it accepts, and how closely two faces must match to be considered the same person — the face on the document against the selfie, and both against the face enrolled the first time this customer verified. You can also express expectations about the person: an accepted age range and, if it matters to you, a gender. Both are estimated from the selfie and are best treated as fraud signals rather than facts — for a real age check, match the date of birth on the document. ## Blocklists chmod can compare the captured face against a blocklist you maintain and against a platform-wide one. These rules are accepted today but not yet enforced; see the field reference for the current status before relying on them. ## Three ways to react Most rules take one of three actions, and this vocabulary runs through the whole configuration: | Action | What happens | | - | - | | **Reject** | The verification fails, and the reason is recorded. | | **Warn** | The verification proceeds, and the finding is recorded for your review. | | **Ignore** | The signal is not evaluated at all. | Ship a new rule as **Warn** first. Watch how often it fires against real traffic, learn its false-positive rate, and only then promote it to **Reject**. It costs nothing and it saves you from rejecting good users on a hunch. ## Time and delivery Two more settings sit alongside the policies. How long the person has to finish the flow — an hour is plenty for a verification started from a button; a day only makes sense for a link sent by email. And where chmod should notify you once the decision exists, so you never have to poll. ## Where the rules live The configuration is built by **your backend**, from your own records, and sent when the transaction is created. Your mobile app never sees it and cannot change it. That boundary is deliberate: a modified app that could lower the liveness threshold or widen the list of accepted documents would be weakening its own verification. The SDK has its own configuration — colours, copy, capture behaviour — and that one is safe to build in the app, because it decides how the flow looks, never what it accepts. ## The field reference Every field, its allowed values, its default and the finding it produces is documented where your backend team will use it: on the [Create transaction](/api-reference/transactions/create-transaction) endpoint, and in the API Reference under [Transaction configuration](/configuration/overview). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.