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:
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 endpoint, and in the
API Reference under Transaction configuration. 
