Savings and investment for Tanzanians, in the language they speak.

The problem

A Tanzanian earning TZS 300,000 a month has no realistic route into a money market fund. The account-opening paperwork assumes a salary slip and a branch visit, the minimums assume a lump sum, and every screen in the process is in English. So the money stays in a mobile money wallet, or in cash.

The same person's relative in London pays a fee they can see to send money home, and a spread inside the exchange rate that they cannot. Nobody shows them the second number.

Two journeys, one product

• Nawekeza Tanzania Domestic

  A customer registers with a phone number, verifies their identity against NIDA, deposits from mobile money from TZS 10,000, buys units in a money market fund, and can redeem or withdraw back to the same verified number. Swahili throughout.

• Nyumbani Diaspora

  A Tanzanian abroad registers with their passport. We confirm with the network who actually holds the recipient's mobile money number before anything moves, and the receipt shows the reference rate, the applied rate and our margin — in basis points and in shillings.

What exists today

A working product, not a deck.

• Backend — 9,200 lines of Python, 39 endpoints, 24 modules.
• Frontend — 16 screens, mobile-first, Swahili by default. Both journeys complete: register, consent, verify, deposit, invest, redeem, withdraw, statement; and sender registration, recipient verification, currency conversion, payout tracking.
• 642 automated tests, all passing — 543 on the API and 99 on the frontend. Five of them walk the two customer journeys end to end against a running API rather than against mocks.

The parts that are not shortcuts

• Double-entry accounting with no stored balances. Every figure a customer sees is computed from the ledger at the moment they ask. A balance cannot disagree with its own history because it has none of its own.
• Four separate PDPA consent records, versioned. Marketing is unticked by default. Cross-border transfer is its own consent, not a clause inside another one.
• Withdrawal to the account's own verified number only. A third-party payout attempt is refused and written to the audit log.
• An FX guard that refuses rather than fills. If the rate has moved beyond a set boundary at the moment of settlement, the conversion is declined and the customer is told — not filled at a worse rate and informed afterwards.
• Per-customer authorisation on every route that moves money or reveals a balance, asserted in the test suite against another customer's session.

What is deliberately simulated

Each rail sits behind an interface, so connecting a real provider is a change of configuration rather than a rewrite. What that is worth depends entirely on how much of the surrounding machinery has ever run, so:

Five external rails. What is simulated, and what is not.

Rail	What is real today	What is waiting on someone else
Cross-border payout	Runs as a separate HTTP service over a real signed webhook, so the client, the HMAC signature scheme, the callback receiver and the refund-on-failure path are all genuinely exercised. The destination country's own payout rules — operator list, limits, permitted decimals — are transcribed from the provider's published documentation and enforced before we send.	Production portal access.
Cross-border collection	The ledger, the quote, the margin record and the settlement boundary around it.	This is the honest gap. Our payout provider's public API is payout-only — there is no documented pay-in endpoint — so the half where money enters the corridor is the one part we cannot reason our way to. It needs a partner conversation, not more code.
Mobile money	The full push-prompt lifecycle: the wallet is credited only on a signature-verified callback, a duplicate callback is a no-op, and an unmatched receipt is posted to a suspense account rather than guessed at.	Aggregator sandbox credentials.
Identity	The decision rule, the review queue, the working-hours service-level clock, and all five outcome states — each with a screen a person can actually be shown.	A verification provider's sandbox key.
SMS and push	Message composition, in both languages.	A gateway contract. Until there is one, the one-time passcode is returned in the response on screen — which is why the product is demonstrable at all, and is obviously not something that survives contact with a real user.

Prices shown inside the product are demonstration prices, and every figure derived from one carries a marker saying so — on the holding, on the total, and on the redemption ceiling. A demonstration price presented as a real one is the most misleading thing this product could put on a screen, so it is labelled in the component rather than in a note somebody has to remember to add.

Where we are

Status as of September 2026. Every line here is checkable.

Product	Both journeys working, demonstrable end to end
Company	Veltro Technologies Limited — registration in progress, BRELA
Licensing	Not licensed. Distribution would be through a licensed fund manager.
Customers	None. Nothing has touched a customer or a shilling.

What we are looking for

• A licensed fund manager whose money market fund we can distribute, and a conversation about what that distribution arrangement would need to look like.
• A cross-border payments partner for the diaspora corridor — specifically the collection side, which is the half we cannot mock our way past.
• Mobile money and identity providers — production access, in Tanzania.

We are not asking for money in this conversation. We are asking whether the thing we have built is the thing you would want to plug into.

Talk to us

One address, read by the person who built this. Both journeys can be walked through end to end in about five minutes, on request.

immanueljuma@gmail.com