Start with identity
Register the legal entity, verify its representatives and maintain a clear record of the authority behind every action.
AFN PROJECT PROPOSAL · FORUS CONNECT
Connected identity.
Shared
opportunity.
A shared foundation for African fintech organisations to onboard, establish trusted identity and present verified evidence across markets.
FORUS proposal · Public project overview
ONE CONNECTED FOUNDATION
⌘
Organisation identityPresented through FORUS Connect
ILLUSTRATIVE Legal entity Representative Credentials
One place to review. One place to approve.
Identity → authority → actionDesigned for trust
Built around the organisationConnected through FORUSPermissions remain explicit
01 / THE VISION
Less fragmentation.
More trusted participation.
AFN connects Africa’s fintech associations around collaboration and financial inclusion. This FORUS proposal supports that ambition with a shared, vendor-neutral approach to organisation identity, representative authority and verified evidence.
Make evidence portable
Present current entity, LEI and licensing information through controlled disclosures, with its source and context intact.
Keep decisions accountable
Record who decided what, for which service and jurisdiction, and when. A signature supports a decision; it does not replace an authority.
02 / THE ORGANISATION JOURNEY
From first application
to connected participation.
Explore the proposed experience. Onboarding comes first; each additional service has its own requirements and approval.
STEP 01 · PROPOSED EXPERIENCE
A clear starting point.
Create an organisation profile, provide registration details and submit the evidence required for the selected organisation type and jurisdiction.
- Save and resume an application
- Review a transparent evidence checklist
- Respond to requests for more information
Starting an application does not require a funded wallet, an LEI purchase or a Ripple account.
03 / FORUS CONNECT
One familiar interface.
Clear authority underneath.
Connect brings identity, organisation context and approvals into the member experience. The infrastructure behind it preserves the checks that make each action trustworthy.
Identify
Keycloak establishes the person’s authenticated session.
PERSONAuthorise
The register checks the organisation and the representative’s mandate.
AUTHORITYApprove
Connect presents the exact action for secure device approval.
INTENTExecute
An authorised service acts, verifies the result and records a receipt.
OUTCOMESimple for members. Consistent for developers.
The FORUS API is designed to handle provider and ledger details behind typed business actions.
Xaman can remain an optional external-wallet integration. Connect approval and blockchain transaction signing retain separate responsibilities.
04 / CONNECTED RECORDS
Connected information.
Distinct meanings.
Each record answers a different question. Keeping them separate makes the overall picture more useful.
Organisation & LEI
Who is the legal entity, and which identifiers and verification evidence describe it?
Legal identity ↗
Passporting evidence
Which authority permits which service, in which jurisdiction, under what conditions?
Scoped recognition ↗
XRPL credentials
What approved assertion has an issuer made about a specific organisation account?
Verifiable assertion ↗
Ripple services
Has the provider accepted the organisation for a particular product, and is it technically ready?
Separate onboarding ↗
An active wallet or credential is not a financial licence. Recognition remains subject to the decisions of the relevant authorities.
05 / OPEN VERIFICATION NETWORK
Many providers.
A shared language for trust.
Bring KYC and KYB providers into a common framework for verifying people and businesses. Start with existing FORUS experience, then agree an open interface that other providers can implement.
Sumsub
Build on FORUS experience with Sumsub in WOW and existing Connect integration foundations.
Extend for the AFN workflowDidit
Extend the existing FORUS adapter and invite participation in shared verification profiles and events.
Validate and map existing capabilitiesChekk
Agree KYC, KYB and registry coverage, including where direct access or offline work is needed.
Scope a new AFN adapter01 / EVIDENCE
Verify the required checks
Keep the provider, source, result and freshness with each person, company and beneficial-owner check.
02 / LOCAL POLICY
Apply country and service rules
Match evidence to approved requirements. A provider's level label alone does not determine eligibility.
03 / EFFECTIVE ACCESS
Confirm the limits in force
Share changes through an agreed webhook format and confirm that the relevant service has applied them.
An open workstream for verification providers.
Co-design evidence profiles, secure event delivery, renewal and revocation, with country-specific requirements and clear operating responsibilities. Provider participation and the common standard remain subject to agreement.
The proposed framework supports interoperability. Each country and regulated service retains its own approval requirements and limits. No confidential provider pricing or customer evidence is published here.
06 / THE BUILD ROADMAP
Build the foundation.
Then extend what it enables.
The proposed sequence combines existing FORUS foundations, platform extensions and new AFN capabilities. These phases describe planned delivery, not completion status.
FUTURE OPTIONS
Member services, when the foundations are ready.
Payments, rewards, institutional treasury, tokenisation and wallet-embedded services can be scoped individually, with their own product, provider and operational requirements.
07 / GOOD TO KNOW
Clarity is part
of the foundation.
A few important distinctions about the proposed platform.
Is this a live onboarding portal?
No. This is a public project overview. It does not accept applications, identity documents, wallet connections or payments. The operational platform will require its own release and acceptance process.
Does this create automatic cross-border permission?
No. The passporting register records evidence and jurisdiction-specific decisions. A competent authority’s permission cannot be replaced by an AFN onboarding decision, a wallet signature or a blockchain credential.
How does Connect relate to Keycloak and Xaman?
Keycloak authenticates the user. Connect presents identity context and obtains approval for an action. An authorised signing service or external-wallet adapter then carries out an eligible transaction. Xaman remains an optional integration rather than a mandatory member interface.
Are XRPL registration and Ripple onboarding the same?
No. XRPL registration concerns the organisation’s account binding and credentials on the ledger. Ripple services onboarding is a separate commercial and technical workflow, subject to product-specific provider approval.
Where are the detailed specifications?
The technical specification, developer work packages, contracts and implementation evidence are maintained separately for the project team. They are not published on this public website.
FORUS PROPOSAL FOR THE AFN ECOSYSTEM