Module and Sub-module navigation
OneView creates a navigation group for each licensed and installed Module. When the Module contains Sub-modules, each
licensed and installed Sub-module appears as a link inside that group. The user also needs verifications:read; a
license alone does not grant access. This permission provides metadata-only history. Stored result previews and detail
views additionally require verifications:results:read, shown as View verification results in the Roles
interface.
For example, open KYC → BVN or KYC → NIN to load the newest 25 records for that Sub-module. Use Previous and Next to move through older pages. Search accepts a verification reference, vendor, or service, and the outcome filter narrows the page to Verified, Processing, Not verified, or Failed records. Search and filter choices remain in the page address while you review the results. Select Refresh to reload the current page.
A direct URL for a Module or Sub-module that is no longer licensed shows an unavailable-license message and does not treat editable browser state as authority.
Current history view
With verifications:read alone, every Sub-module uses a metadata-only table showing:
- a shortened request reference;
- the outcome;
- the vendor service; and
- the completion date.
The metadata-only table does not reveal result-derived summaries, names, identity fields, photos, or a control for opening verification details.
With both verifications:read and verifications:results:read, released KYC Sub-modules use result-focused tables:
| Sub-module | Result-focused table preview |
|---|---|
| BVN | Supported portrait when supplied, first name, last name, state of origin, and gender |
| NIN | Name, date of birth, gender, state of origin, and suspension status |
| Driver's License | Name, date of birth, gender, issue and expiry dates, and state of issue |
| International Passport | Name, date of birth, gender, issue and expiry dates, document type, and place of issue |
| CAC | Company name, company type, status, registration date, state, city, LGA, and affiliate count |
| TIN | Taxpayer name, entity type, tax office, status, and CAC registration number |
| PEP Screening | Searched name, outcome, match indicator, match count, provider guidance, and manual-review status |
| Sanction Screening | Searched name, outcome, match indicator, match count, provider guidance, and manual-review status |
NIN results from a supported Smile ID service may also include the match outcome and reason returned for the submitted comparison. Exact preview values depend on the selected released provider service. An unavailable marker means that the provider did not return a usable value; it is not proof that the underlying identity or registration record lacks that value.
Previews do not include raw provider fields, contact details, street addresses, submitted query identifiers, TIN values, or photos other than the optional supported BVN portrait. Use the detail view for the stored normalized result rather than treating a table preview as complete.
PEP Screening can include bounded normalized match details in its authorised detail view. OpenSanctions PEP and
Sanction results expose only bounded normalized screening fields; their match confidence describes candidate
similarity, not subject risk. Prembly Sanction Screening does not include nested match details in v1. Use the client's
approved manual-review process when any screening outcome is potential_match, match, or inconclusive.
An authorised result reviewer can select a result-focused row, or View where presented, to open Verification details. The drawer identifies the vendor service, outcome, Module, Sub-module, environment, and completion time. Its Request tab shows the safe request context: reference, purpose, Module, Sub-module, vendor, service, environment, adapter version, and creation and completion times. It does not show the submitted identity fields, connection credentials, or raw provider request.
The Result tab presents available safe normalized fields as labelled values. Person results lead with the normalized name; BVN also shows its supported portrait when available. Company and tax results use organisation-focused labels. A failed record instead shows its safe OneView error code and message; a processing record shows that its result is pending.
The history workspace is read-only. It does not expose raw provider responses, one-click retry, export, or deletion. Not provided means the request omitted purpose or supplied it blank. A dash means another value is unavailable; it does not prove that the caller or provider intentionally omitted it.
OneView records each authorised result preview and detail view against the affected verification. Attempts to reveal a result without View verification results are denied and recorded. These activity events contain no normalized result fields, identity values, photos, or other result contents. See Activity logs.
A browser user with verifications:execute can select New Verification on the current Sub-module page. The
Sub-module is already selected; choose an active connection, optionally enter a purpose in the single-line input,
complete the service fields, and select Run verification. The form remains visible beside or above the persistent
result panel. After completion, that panel shows the normalized result in a read-only structured JSON view, or a safe
failure, without leaving the Sub-module page.
External client systems use an API Service Account, as described in the synchronous API. A Sub-module appearing in navigation is not proof that its service, connection, or production provider credentials are ready.
Safe review example
For testing and screenshots, use a provider-approved synthetic subject reference such as SANDBOX-CASE-001; never use
a real NIN, BVN, name, address, date of birth, phone number, image, or biometric in documentation or support evidence.
When investigating a failed row:
- Record the shortened safe reference, Module, Sub-module, vendor service, outcome, and timestamp. An authorised result reviewer may also record the safe error code shown in the detail view.
- Confirm the expected adapter and active preferred connection under Vendor connections.
- Review client-approved application logs locally.
- Follow the support-redaction rules before sharing evidence.
When an uncertain API call used an idempotency key, repeat the same key with the exact same connection, normalized
purpose, and data to retrieve the earlier outcome. An absent purpose and a supplied purpose are different requests;
adding, removing, or changing purpose with a reused key returns an HTTP 409 conflict. A changed request needs a new
key and is safe only when the released service contract provides an explicit replay or reconciliation procedure.
Calls that omitted the header cannot use this retry protection.