Appearance
Administration overview
Everything under Settings, and what each screen is responsible for. If you are not sure which screen owns a behaviour, this is the map.
| Screen | Owns | Permission |
|---|---|---|
| Team | Who has access, and what they may do | account.team.manage |
| Country defaults | Which countries are usable, which checks run at intake, what screening classifications mean, which activities are prohibited | country_configuration.manage |
| Risk model | Factors, weights, per-value scores, tier boundaries | risk_configuration.manage |
| Standing bars | Who is barred from future acceptance, and scheme listings | denylist.manage |
| Screening lists | Which watchlists sanctions and PEP screening runs against | screening_configuration.manage |
| API keys | Machine credentials and their scopes | api_key.manage |
| Providers | What Verity declares to Elm on every request: the usage code and operator id | provider_configuration.manage |
| Webhook endpoints | Where Verity posts review events | webhook_endpoint.manage |
| Webhook deliveries | Whether those posts arrived | webhook_delivery.view |
| Audit activity | Who did what | audit_event.view |
Which screen changes what
A useful way to keep them apart — each answers a different question:
| Question | Screen |
|---|---|
| Why can this person not approve? | Team |
| Why did no checks run when I created a merchant? | Country defaults → intake checks |
| Why is this gate "not assessed"? | Country defaults → activity rules |
| Why does a PEP match block here but not there? | Country defaults → screening dispositions |
| Why is this merchant medium and not high? | Risk model → factors, weights, tiers |
| Why can this merchant never be approved? | Standing bars |
| Why did screening refuse to run? | Screening lists — a subject type with no list behind it |
| Why does the API return 401? | API keys |
| Why is Yakeen rejecting our usage code? | Providers — and check which source the value came from |
| Why did my system not hear about an approval? | Webhook endpoints and deliveries |
| Who approved this, and what did they know? | Audit activity |
Setting up a new account
In order, because each step depends on the one before:
- Country defaults — add and activate at least one country. Nothing can be created without this, and the intake checks you select here become the checks that block approval later.
- Risk model — install the default factors, then fill in country risk and legal form, which ship deliberately empty. Set the tier boundaries.
- Team — invite people against role templates.
- API keys and webhooks — only if something is integrating.
Two tables ship empty on purpose
Country risk and legal form arrive with no scores. Ranking legal forms is a credit judgement and a country risk table is a compliance artifact — neither is something the product should invent. Until they are filled in, four of the twenty-one default weight points can never be evidenced.
What administration cannot do
No setting here assesses anyone, approves anything, or changes a past decision. Tier boundaries label a score; they do not create one. An assessment already made keeps the thresholds it was scored against.