Azertica Yonna Group

Confidential Proposal

Enter the password shared with you by Azertica to view this proposal.

Incorrect password. Please try again.
{{ unlockFx }}
Azertica Yonna Group
Technical and Commercial Proposal · Confidential

Digital Platforms for Yonna Group

Seven businesses under one ownership, each on its own systems. What Azertica proposes for each one, and what becomes possible once they are connected.

Prepared for
Yonna Group, Republic of The Gambia
Prepared by
Azertica
Validity
45 days from the date of issue
Priority Proposals

Where We Propose to Start

01 · Purpose

Purpose of this Document

This document follows our visit to Yonna Group. Yonna operates seven distinct businesses under one ownership: a foreign exchange bureau, a mobile wallet, a Shariah-compliant insurer, an Islamic microfinance institution, an import and distribution company, an agribusiness venture, and a telecom. Each runs on its own systems, largely disconnected from the others.

This document sets out what Azertica proposes for each of the seven businesses individually, then what becomes possible once they are connected. It closes with a recommended order to take them in, a delivery approach, and next steps.

02 · Context

Shared Ownership, Separate Systems

The seven businesses share ownership but not infrastructure. Each has grown on its own systems and habits, shaped by what that particular business needed at the time. That independence has let each one move at its own pace, but it also means the group has no shared view of its own customers, no common compliance process, and no way to see across the businesses at once.

The proposals in sections 4 to 10 are written for each business on its own terms, solving the problems specific to it. Section 11 then describes what a shared layer across all seven could add, once individual needs are met.

The most valuable part of this proposal is not any single business: it is what connecting the seven makes possible.

We flag it here, early, because it is easy to lose sight of that while reading seven business-by-business sections in a row. Jump to the group platform →

03 · Approach

How We've Approached This

Seven businesses at once is a lot to take in together, so each gets its own section, written to the same length, in the order Yonna's own materials listed them rather than by any ranking of importance.

Equal length does not mean equal certainty. The Foreign Exchange Bureau and the Islamic Microfinance proposals are built on a reasonably clear picture of how those businesses run. Wallet and Agribusiness are not: both sections are a starting point for a conversation, not a reflection of how well we understand those two businesses today, and we say so again where they appear.

04–10 · The Businesses

Seven Businesses, Each on Its Own Terms

Listed in the order Yonna's own materials present them.

Section {{ active.num }} Provisional proposal

{{ active.name }}

{{ p }}
→ {{ it.t }}
{{ it.d }}
← Previous Next business →
Section {{ b.num }} Provisional proposal

{{ b.name }}

{{ p }}
→ {{ it.t }}
{{ it.d }}
11 · The Group Platform

The Yonna Group Platform

Each business above can be improved on its own terms, independently of the others. But four things only become possible once the seven are connected, and none of them require replacing what each business already runs.

{{ l.n }} {{ l.t }}

{{ l.d }}
Regulatory

Layers 2 and 4 share customer data across a bank-interoperable wallet, an MFI, and an insurer, each of which likely answers to its own regulator. We treat that as a compliance question to settle with the Central Bank of The Gambia and the insurance regulator before build, not as a detail to resolve during implementation.

12 · Sequencing

Recommended Sequencing

Seven businesses cannot be taken on at once, and they should not be. We recommend an order based on two things: how far each business's current process is from what a platform would provide, and how much groundwork we already have to act on.

  1. {{ s.o }} {{ s.b }}

    {{ s.w }}

    2.
13 · Assumptions

Assumptions and Dependencies

Seven businesses means seven points of coordination, not one. The sequence in section 12 and the timeline in any individual project both depend on the following being in place.

{{ d.t }}

{{ d.d }}
14 · Delivery

Delivery Approach

Each business is scoped and delivered as its own project, on the sequence above, starting with a short discovery phase to confirm current processes, data, and priorities with the team that runs it day to day. Nothing is built against assumptions alone.

The platform layers in section 11 are introduced progressively as each business comes online, rather than as a single upfront undertaking. This keeps each phase useful on its own, whether or not a later phase happens on the same timeline.

15 · Why Azertica

Why Azertica

Azertica already builds for regulated, compliance-heavy sectors in the sub-region, including finance and health, and works with institutional counterparts such as Senegal's Ministry of Health and a regional central bank.

Offline-first design is standard practice for us, not an afterthought, which matters for field operations such as YIMF's agents or the Bureau's branch network.
Phase 1 · Priority Yonna Islamic Insurance

Takaful Claims Management System

A web and mobile system that takes every claim from declaration to payout, with full traceability and Shariah-compliant reporting.

Primary entity
Yonna Islamic Insurance
Indicative duration
12 to 14 weeks
Starts with
A 2-week discovery
Problem today

Claims are processed manually, which means slow settlement, no visibility on pending volumes, and limited protection against fraud or duplicates.

Claim Flow

From Declaration to Payout

Every step is timestamped, so management sees settlement time and backlog per branch and per product.

Azertica builds Yonna's team and systems
Azertica builds
Declaration Engine
→
Azertica builds
Document Processing Engine
→
Fraud Engine Azertica builds
Claim data
From YonnaPass · other Yonna entities
{{ x }}
{{ x }}
▼
Risk check
Every claim scored against all signals
Pass
→
Yonna's claims team
Approval Process
Accepted
→
Yonna Wallet
Payout
FRAUD↓
Rejected↓
Yonna's team
Fraud Process
Customer
Notified by SMS

What Azertica Builds

{{ b.who }}
{{ b.t }}

{{ it }}
Core Features

What the System Does

{{ f.n }} {{ f.t }}
Takaful-Specific

Reporting

→ {{ r }}
Potential Gains

What Faster Claims Could Save

Less manual handling per claim, fewer fraudulent or duplicate payouts, and faster settlement for customers.

Assumptions · adjust to Yonna's figures
Potential per year
{{ cmTotal }}
{{ cmTotalNote }}
{{ o.v }}
{{ o.l }}

Illustrative estimate from the assumptions above. Figures will be replaced with Yonna's real volumes and costs during discovery.

Optional Extension

Health takaful

For health takaful products, direct connection with partner clinics running JammSanté, Azertica's hospital management platform, so providers submit claims electronically.

Deliverable

Production system, staff training, and 3 months of post-launch support.

Next Steps

Proposed Next Steps

Azertica starts with a 2-week discovery on the claims system, then delivers Phase 1 in about 3 months and Phase 2 over the following 6 months.

  • {{ s }}
Phase 2 · Priority Unified customer identity and KYC

YonnaPass: One Identity for Every Yonna Service

YonnaPass is a single verified identity that lets a customer open, use and move between every Yonna service without registering twice.

Yonna customer ID
verified once
▼
{{ e }}

Verify once, serve everywhere.

What YonnaPass Is

One Yonna. One Pass.

Today a customer is likely registered separately in each entity. A single identity cuts onboarding cost, strengthens AML controls, and lets Yonna offer products across entities (a Y Cell subscriber becomes a wallet user, then a financing or takaful customer).

Promise to the customer

Show your ID once, at any Yonna branch or on your phone, and you are recognised everywhere: Y Cell, Yonna Wallet, Yonna Islamic Microfinance, Yonna Islamic Insurance and Yonna Forex Bureau.

Promise to Yonna

One view of each customer across the group, lower onboarding cost, stronger anti-fraud and AML controls, and a natural path to sell more services to the same customer.

Why the Name Works

→ {{ n }}
Customer Journey

Register Once, Grow With Yonna

A customer registers once, then each new Yonna service reuses what is already verified. Each step adds history to the same profile, so the customer's options grow as their relationship with Yonna grows.

{{ j.n }}
{{ j.t }}
{{ j.s }}
{{ j.arrow }}

What the Customer Gets

{{ g }}
Before and After

Five Registrations Become One

Today a customer is likely registered separately in each entity. With YonnaPass, the identity check happens once and every entity reuses it.

Today 5 forms · 5 ID checks · 5 records
{{ e }}
Own form
Own ID check
Own record
With YonnaPass 1 form · 1 ID check · 1 profile
YonnaPass: form, ID check and profile, once
▼
{{ e }}
Reuses profile
Use Cases

Where YonnaPass Pays Off

Six paths a customer or a Yonna team can take. Blue steps are where YonnaPass does the work: an identity check that is not repeated, or a signal carried from one entity to another.

{{ uc.title }}

{{ uc.who }}
{{ s.e }}
{{ s.t }}
{{ s.l }}
{{ s.arrow }}
Without YonnaPass

{{ uc.without }}

With YonnaPass

{{ uc.with }}

← Previous Next use case →
Benefits by Entity

What Each Entity Gains From the Others

Once the five share one verified profile, information that one entity already holds becomes useful to another, always within the customer's consent.

{{ x.src }} {{ x.info }}
▶
Receives
{{ b.e }}
What it gains

{{ b.gain }}
Potential Gains

What One Identity Could Save

Every customer who is already known to another Yonna entity is one registration, one ID check and one paper file Yonna no longer repeats.

Assumptions · adjust to Yonna's figures
Potential per year
{{ ypTotal }}
{{ ypTotalNote }}
{{ o.v }}
{{ o.l }}

Illustrative estimate from the assumptions above. Figures will be replaced with Yonna's real volumes and costs during discovery.

Verification Levels

Start Quickly, Verify More When Needed

YonnaPass has three levels, so customers start quickly and verify more only when they need higher-value services.

Level {{ l.n }}
{{ l.name }}
What is checked
{{ l.check }}
What it unlocks
{{ l.unlock }}

Exact limits per level will be set with Yonna's compliance team to match the requirements of each licensed entity.

Architecture

A Central Registry With Secure APIs

Entities connect to YonnaPass rather than copying customer data between each other.

YonnaPass registry
profiles, documents, consent
▼
Branch onboarding app
▶
YonnaPass API
access by role and entity
▼
{{ e }}

Key Design Choices

{{ d }}
Features

For Yonna's Entities and Staff

Each entity keeps its own systems and connects to YonnaPass to read and update the shared customer profile.

{{ g.t }}

{{ it }}
Consent & Compliance

Consent, Privacy and Compliance

Customers decide which Yonna entities can use their profile, and every use is logged.

Open question for Yonna: which data protection, KYC and AML requirements from the Central Bank of The Gambia and the telecom regulator apply to each entity today. This will be confirmed in discovery before any data is shared across entities.
→ {{ c }}
Rollout Plan

Live in About 6 Months

YonnaPass launches in about 6 months, starting with Y Cell and Yonna Wallet, where most new customers arrive.

Months {{ r.m }}
{{ r.s }}
{{ r.d }}
Next Steps

Proposed Next Steps

Deliverable: registry, APIs, onboarding app for branches, and migration of existing customer records.

  • {{ s }}