Appearance
Country defaults
Settings → Country defaults, needing country_configuration.manage.
A country configuration is what makes a country usable. An entity cannot be created for a country with no active configuration on the account.
Adding a country
This screen lists the countries an account already has and lets you edit each one. It cannot add a country: one with no configuration does not appear here at all.
bash
bin/rails countries:activate COUNTRY=BH ACCOUNT_ID=2bin/rails countries:list shows which countries each account has, and the intake checks each requires.
The task is idempotent and states what it did. ACCOUNT_ID is required when more than one account exists — a task with more than one possible target must be told which, rather than picking the first row.
The intake checks are derived, not chosen
They come from CheckCoverage — what a provider can actually run in that country — intersected with the checks allowed at intake. So a country can never be activated requiring a check no provider covers there.
Bahrain gets commercial_registration through Sijilat and none of the Elm or Wathq checks, without anyone having to remember which is which.
What activating a country does not give you
The task prints these at the point of activation, because the gap between "the country is on" and "everything works there" is where the surprises are.
Signing. Bahrain has no signing provider built — it needs eKey with BENEFIT/OneSign. Contracts can be prepared and read there, but not signed.
Owner screening. Sijilat returns owners with no identifier, so a Bahraini owner cannot be screened as a person until one is supplied by hand.
Nothing else is needed: Sijilat's credentials are public values with working defaults, so no new environment variable is required to onboard a Bahraini merchant.
What a country can actually check
The menu shows only the checks with a provider in that country, and names the ones without.
Most of Verity's providers are Saudi: Wathq's ancillary services, Elm Yakeen for identity, Neotek for IBANs. Commercial registration is the exception — it runs for Bahrain too, through Sijilat. What else travels is screening (a sanctions list does not stop at a border) and the checks that read our own data or the open web.
| Runs anywhere | Saudi + Bahrain | Saudi Arabia only |
|---|---|---|
| Organization + individual screening | Commercial registration | Commercial contract |
| Portfolio linkage | Identity, address and digital ID verification | |
| Website content, domain intelligence | National address, employment, registry relations, IBAN |
So a Bahraini merchant can be registry-verified, screened, and linked to the rest of the portfolio — but not identity-verified (Elm has no reach there) or IBAN-checked. That is a gap in coverage rather than a finding about the merchant, and the screen names what is missing rather than leaving a shorter list to be read as a bug.
Bahrain's registry comes without dates of birth and gives owners no identifier, so a Bahraini merchant's owners appear as evidence but cannot be resolved to verified people — see calendars.
This used to be silent
Every country was offered the identical Saudi menu, and only one check in fourteen knew what country it was in. Requiring commercial registration in Bahrain sent that merchant's number to the Saudi registry, which returned not-found — reported as "commercial registration failed", a statement about the merchant rather than about our reach. Held now by an invariant that walks every check against every country.
What it controls
Intake checks
Which checks run automatically when an entity is created in this country. Chosen from: commercial registration, organization screening, individual screening, identity verification, address verification.
These are also what blocks approval if they have not completed — configuring a check here makes it required, not merely offered.
Screening dispositions
What a screening classification means in this country: whether a PEP match blocks approval, escalates, or merely informs. This is the single source the approval guard and the screening panel both read, so the panel and the block can never disagree.
Activity rules
Which ISIC activity codes are prohibited and which are high risk in this country.
These drive three gates and the activity_flag risk factor. Until a country has activity rules configured, those gates report not assessed rather than clear — an unconfigured country means nothing was judged against policy, which is not a clean result.
The ISIC vocabulary
Activity codes come from the ISIC vocabulary synced from Wathq. Every level-3 code carries a regulating authority, which is the signal behind the "licence for a regulated activity" gate.
If the vocabulary has not been synced, the entity page says so rather than presenting an unmatched activity list as clean.
Registration number formats
Per-country validation. Saudi Arabia requires the 10-digit unified number beginning with 7 (7XXXXXXXXX). Countries without a rule accept any non-blank value.
Seeded countries
Saudi Arabia, United Arab Emirates, Kuwait, Qatar, Bahrain and Oman are seeded. Only Saudi Arabia has provider integrations; the others exist so entities can be recorded, and their checks will be limited accordingly.
