Verified capital, from ore to return.
How Aleko Capital gives an investor real, sanitized proof that mineral-procurement capital in Kenya is turning into tracked physical product and real cash returns - without exposing vendor pricing, staff data, or the internal ledger.
Background
Why this platform exists, and what problem it's actually solving.
Aleko Capital is an investment partnership doing mineral exploration and procurement in Kenya. An investor provides the capital; a Kenya-based team runs the ground operation - buying ore from artisanal miners, transporting it, processing it, and selling the refined product. The investor and the operating team are not the same people, which means the core problem is trust without exposure: the investor needs proof their capital is real and moving correctly, and Aleko needs to keep vendor pricing, supplier identities, and staff pay confidential.
This platform is that proof. Every physical step - a purchase, a scale reading, a truck's route, a lab result - writes a digital record before money moves. The investor sees the aggregate result of that record in real time. They never see the record's confidential detail.
The opportunity
Why this gap exists, and why closing it is worth capital.
Kenya's artisanal and small-scale mining sector moves real, valuable gold every day, sourced by hand, at small scale, largely outside formal, bankable, or investable channels. Not because the gold isn't real. Because there has historically been no system-level way for a capital provider sitting outside the operation to verify that a shilling deployed into procurement actually became a gram of verified ore, and that the ore became cash, without either party having to simply trust the other's word.
That gap is a financing problem, not a geology problem. Ore reserves and buyer demand already exist. What's been missing is the verification layer that lets outside capital participate without needing to be on the ground to believe the numbers. That's the specific, narrow thing this platform is built to close.
Why this, not the status quo
The same procurement chain, with and without a verification layer underneath it.
| Point of failure | Trust-based procurement | This platform |
|---|---|---|
| Proof of purchase | Paper trail, unverifiable after the fact | Digital PO, weigh ticket, and invoice, matched automatically |
| Payment control | One person can request and approve the same payment | Maker-checker enforced at the database level, not just policy |
| Weight accuracy | Manual scale reading, disputable after delivery | IoT scale feed; any manual override is flagged and requires a reason |
| Investor visibility | Periodic reports, after the money has already moved | Real-time, sanitized dashboard, before and after |
| Fraud detection | Found after the loss, if at all | Recovery variance auto-flagged the moment it exceeds 1.5% |
| Audit trail | Reconstructed from memory and paperwork | Append-only log; nothing can be edited or deleted, ever |
How it works
Seven steps, from capital arriving to cash returning - each one gated by a digital control, not a person's word.
Investor capital arrives
Buying raw ore
Weighing the ore
Transporting the material
Three-way payment matching
Processing & purity testing
Final sale & cash returned
The seven rules underneath all seven steps
Every step above exists to enforce one of these. They're the actual governing logic, not a slogan layered on top of it.
01
- No material movement without a record
02
- No financial movement without an approval
03
- No inventory movement without reconciliation
04
- No supplier without verification
05
- No payment without supporting documentation
06
- No adjustment without an audit trail
07
- No material exception without explanation
Capital velocity
How long a shilling stays in motion before it comes back as cash. Illustrative timing, actual duration depends on hub volume and buyer terms.
The architecture
Five layers, from the apps people touch down to where the record actually lives.
Who's on the platform
Every account has exactly one role, and the platform enforces what that role can see and touch - not just the interface, the data itself.
Investor
- Sees
- Aggregate capital, verified inventory, recovery %, realized sales
- Can do
- Nothing but read - no write access exists for this role
- Never sees
- Supplier names, itemized pricing, staff pay or bank details
Exec Admin
- Sees
- Everything, unmasked, across every hub
- Can do
- Final overrides, user & role management
Approver (checker)
- Sees
- Full detail within their assigned hub(s)
- Can do
- Approve or reject purchase orders, payments, assays - never their own requests
Field Officer (maker)
- Sees
- Their own hub's transactions
- Can do
- Create intake, request purchase orders, log weigh tickets - cannot approve anything they created
Driver / Runner
- Sees
- Their own active route and trip
- Can do
- Trip check-ins, delivery confirmation - always GPS-tracked while active
Compliance Auditor
- Sees
- Audit logs, KYC vault, licence status - global, read-only
- Can do
- Flag or escalate; nothing more
What triggers what
A purchase order's path from request to cash out, hop by hop.
PO created
Field officer requests a purchase against a hub.
PO approved
A different person, the approver, signs off.
Weighed in
Digital scale reports net weight; overrides are flagged.
Invoice submitted
Supplier's invoice enters the match.
Three-way match
PO + weight + invoice compared. Green pays, red freezes.
Payment approved
A second person confirms release, never the requester.
Payout sent
Funds move via M-Pesa or bank rail.
Maker-checker, the green/red match, and the append-only audit trail all sit inside this one chain, not bolted on afterward. A purchase can't skip a step, and it can't move money without the record to back it up.
What's captured, what's stored
Every physical event becomes a record before it becomes a payment.
Captured at the source
- Gross / tare / net weight, straight from the scale
- Purity grade from the XRF reader
- GPS position, speed, geofence status
- Lab assay estimates vs. actual recovery
- Document hashes (SHA-256) at upload
Where it lives
- Relational database - the system of record, 30 tables
- Cache layer - session state and the live GPS-ping buffer
- Object storage - hashed documents and receipts
- Append-only audit log - never updated, never deleted
How systems talk
- Field devices & scales → webhook → central API
- Staff apps → token-authenticated REST calls
- Investor & admin views → same API, different filter
- Every response passes a masking layer before it leaves
Risk & mitigation
The same controls from §04 and §08, read as answers to the questions a capital provider actually asks.
| Risk | How the platform addresses it |
|---|---|
| Ore diversion or theft | Every gram is weighed by an IoT scale and tied to a Digital Batch ID; a manual override is always flagged and requires a written reason. |
| Payment fraud or self-dealing | Maker-checker is enforced at the database level, the person who requests a payment can never be the one who approves it. |
| Invoice or weight manipulation | The three-way match blocks payment unless the purchase order, scale weight, and invoice all agree. |
| Processing shortfall, theft or inefficiency | Recovery more than 1.5% below the pre-process estimate auto-flags the batch for investigation. |
| Supplier or hub illegitimacy | A hub's cooperative licence is checked before any purchase order can be issued against it, and an expired licence auto-suspends the hub. |
| Diversion in transit | GPS and geofencing flag an unauthorized stop or route deviation the moment it happens, not after delivery. |
| Cover-up after the fact | The audit log is append-only. Nothing can be edited or deleted, by anyone, ever. |
Systems we rely on
The outside verification and payment partners that keep the platform's numbers honest.
| Service | What it verifies | Est. running cost |
|---|---|---|
| Safaricom M-Pesa Daraja | Mobile-money payouts to miners & hubs | ~$8/mo + 1-1.5% per payout |
| Zoho Books | Accounting sync, tax & ledger records | $15-$40/mo |
| Smile Identity | National ID verification for hubs & suppliers | ~$50-$300/mo |
| Google Maps Platform | Live GPS map & geofencing | $0-$200/mo |
| Africa's Talking | SMS alerts to field staff | $20-$100/mo |
| Crypto / stablecoin rail | Alternative investor funding rail | Provider TBD |
Live dashboard preview
A working preview of the command-centre view - simulated here so you can see the shape of it before the real feed is wired in.
Live Order Feed
Station Performance
Assay Status
Invoices & Payments
Notifications
Hub Status
This is a concept preview of the command-centre view, built to show the shape of it before the real feed is wired in. It's the general operations view, §13 breaks down how each of the six roles sees something different. USD figures are illustrative, converted at an assumed gold price for demonstration only.
What each role sees
Same platform, six different screens - because the access rules in §07 aren't just permissions, they change what's actually rendered. Pick a role.
Capital Deployed - Last 7 Months
Recent Hubs
Verified Batches
Read-only. No vendor names, no itemized pricing, no staff data - ever, at any zoom level.
Recent Hubs (unmasked)
Freeze All Disbursements
Exec-admin override - logged with a reason code either way.
Active Accounts
Same data as the investor view, same day - but unmasked, plus the override and staff controls only exec_admin holds.
The platform blocks approving your own request outright - this queue only ever shows requests someone else made.
Sub-30-second entry per the target workflow - scan the miner's QR, read the scale, done. Swipe through: queue → intake → receipt.
GPS-tracked the entire time this screen is open - an unplanned stop alerts the command centre before the driver does anything.
| Time | Actor | Action | Entity | Reason |
|---|---|---|---|---|
| 09:14:02 | field_officer_23 | weigh_ticket.override | WT-0417 | scale offline, manual read |
| 09:22:47 | approver_08 | purchase_order.approve | PO-0230 | - |
| 09:31:15 | system | three_way_match.evaluate | TWM-0512 | green_match |
| 09:40:03 | exec_admin_02 | payment.freeze | PAY-0118 | invoice/scale mismatch |
| 09:52:31 | field_officer_09 | hub.miner_registered | MINER-MGR-118 | - |
Read-only by design - there is no edit or delete control anywhere on this screen, because the underlying table doesn't have one either.
Invoice tracking & ground-team approval
How a supplier's invoice gets tracked from submission to payment, and how the field team gets an assay in front of an approver before money moves.
How invoice tracking works
A field officer or supplier submits the invoice against a specific batch. The platform links it automatically to that batch's Purchase Order and Weigh Ticket by batch ID, so no one has to manually connect the three records. The three-way match runs the moment all three exist, and the approver is notified either way.
Process overview
Ground-team approval thread
An assay result needs context, not just a number, before an approver signs off on releasing payment. Each assay gets a short thread attached to it: the field team can upload the report and flag anything unusual, the approver can ask a question or approve right there.
What this means for the investor relationship
The short version of everything above.
Trust, without exposure
Every stage, capital arriving, ore purchased, weighed, matched, paid, refined, and sold, writes a record before money or material moves. The investor sees the outcome of that record in real time. They never see the confidential detail behind it.
Control, not paperwork
Maker-checker, the three-way match, and the append-only audit trail aren't reports generated after the fact, they're gates the transaction has to pass through to happen at all.