Authenticity verification
“Did a registered institution sign this, and has it been changed since?”
Limit. Proves origin and integrity only for content signed by that institution. Unsigned content is “unknown”, not “fake”.
Business model
A safer digital world. Built to scale.
Tumaini gives people a simpler way to check suspicious content and gives institutions the infrastructure to protect their customers.
Free protection for people. Trusted infrastructure for organisations.
Status key
- Implemented and tested
- Simulated in prototype
- Planned
- Proposed commercial
No customers, pilots or partnerships yet.
Organisations named in this page are prospective categories or targets. Figures are illustrative assumptions. Nothing here is existing income or an agreed deal.
Choose a format
The same business model, in four formats.
Read the full page for the reasoning, or take the summary or the slides into a meeting. The pitch deck is the version presented to the judges.
- 01
Full page
This page: the canvas, the three checks, the revenue model, the pilot and the status behind every claim.
On the web
Read on this page
- 02
One-page summary
The nine blocks on one A4 landscape sheet, for print or a quick read before a meeting.
Web · PDF · Print
Open the summary
- 03
16:9 slides
Six slides on the business model, sized for a screen or a projector, with the same statuses.
Web · PDF · Print
Open the slides
- 04
Pitch deck
The full ten-slide Tumaini pitch, with a page that lets you check each claim against the live site.
Canva · Full screen
Open the deck
How value moves
Protection reaches people through the institutions they already trust.
The exchange works in five steps. Residents never pay to check a message. Institutions pay for integration and usage, and their customers benefit.
- 01People receive suspicious content.
- 02Tumaini helps assess the risk and verify what can be verified.
- 03Institutions integrate verification into important customer interactions.
- 04Institutions pay for platform access and usage.
- 05Protection becomes available wherever the integration is deployed.
Steps 3 to 5 describe the model, not current deployments. The prototype simulates payments and delivery. For how the verification works, see the Technology page.
The canvas
Nine blocks. One business.
Each block is a working hypothesis. Every claim carries a status so the difference between what runs today and what we propose stays visible.
Block 1: Customer segments
Institutions pay. People are protected.
Paying customers
- Banks and payment providers
- Fintech companies with payment or identity-sensitive flows
- Government digital-service providers that are impersonated
- Digital platforms with identity-sensitive interactions
- Enterprises facing impersonation and payment-fraud risk
End users (protected, never charged to check)
- Families and older residents
- Children and young people
- People receiving suspicious voice notes, messages, images or videos
- People with accessibility needs
Institutions finance the integration; end users benefit from it.
Relates to blocks 2 and 5
Block 2: Value propositions
Three audiences, three different promises.
For people
- Know what to trust before you act.
For institutions
- Protect customers from impersonation and fraudulent requests inside the experiences they already use.
For developers
- Add trusted verification capabilities without building the entire infrastructure from scratch.Implemented and tested
Authenticity, manipulation detection and fraud-risk assessment are different checks with different limits. See “Three different checks” below.
Relates to blocks 1 and 3
Block 3: Channels
Institutions sell and deploy. Developers evaluate.
- Institutional sales to fraud, digital-channel and security teamsProposed commercial
- Banking and fintech partnershipsProposed commercial
- Government digital-service integrationsProposed commercial
- Developer documentation, sandbox and verification APIImplemented and tested
- Enterprise pilotsProposed commercial
- Public demonstration websiteImplemented and tested
- Consumer companion app, Tumaini AssistPlanned
Relates to blocks 1 and 4
Block 4: Customer relationships
Onboarding, support and evidence for every decision.
- Institutional onboarding and technical integration supportProposed commercial
- Customer success and quarterly reviewsProposed commercial
- Compliance and trust documentation, including limitations and evaluation
- Incident review and reporting in the institution portalImplemented and tested
- Usage analytics on verification activityImplemented and tested
- Service-level agreements for future production contracts. None are offered today.Planned
Relates to blocks 3 and 5
Block 5: Revenue streams
B2B first. Residents never pay.
Proposed commercial- A. Institutional subscription: platform access, trust management, reporting and support
- B. Verification usage: signed-message checks, media analysis, provenance and enhanced risk analysis
- C. Enterprise integration: scoped deployment, onboarding and support services
Not revenue streams: advertising, or selling personal data. Pricing is set after pilot cost validation.
Relates to blocks 1 and 9
Block 6: Key resources
Trust infrastructure, evaluated models and people.
- Verification infrastructure: signed receipts and a trust registryImplemented and tested
- Cryptographic trust: Ed25519 signatures and C2PA verificationImplemented and tested
- Evaluated voice-analysis component, measured on public datasetsImplemented and tested
- Trusted issuer registry: demo only, not an official registrySimulated in prototype
- Security, ML evaluation and Arabic language expertise
- Institutional relationships. None signed.Planned
Commercial dependency: the current voice-analysis model’s weights are CC BY-NC-SA 4.0 (non-commercial). A paid deployment needs a commercial licence or a licensed or self-trained replacement, re-evaluated before launch.
Relates to blocks 7 and 9
Block 7: Key activities
Run it safely, measure it honestly, onboard carefully.
- Maintaining verification infrastructure and key lifecycle
- Improving evaluation and reliability; re-measuring before every model change
- Protecting user privacy and minimising retained data
- Onboarding institutions and supporting integrations
- Monitoring operational performance and investigating reported impersonation
- Evaluating emerging fraud and voice-cloning methods
Relates to blocks 6 and 4
Block 8: Key partners
Prospective categories. No partnership is signed.
Proposed commercial- Banks and fintechs
- Government entities
- Digital identity providers
- Cybersecurity organisations
- AI model and infrastructure providers, including a commercial licence for the voice model
- Research institutions for Arabic evaluation data
- Telecommunications and messaging ecosystems
Relates to blocks 6 and 7
Block 9: Cost structure
Mostly fixed people and compliance costs, plus a per-check variable cost.
Fixed operating costs
- Engineering, security and ML staff
- Security operations and independent penetration tests
- Certifications required by banks, for example ISO/IEC 27001
- Key management (HSM or cloud KMS)
- Legal, privacy and compliance review
- Enterprise sales, onboarding and customer support
- Model licence: fixed or per-use, not yet known
Variable verification costs
- AI inference and compute for audio analysis (CPU)
- Transcription compute
- Hosting and bandwidth per check
Cost per verification has not been measured in a pilot. The prototype takes about 6 to 9 seconds per 11-second voice note on a 2-vCPU container.
Relates to blocks 5 and 7
Numbers show the canonical canvas order. On mobile, blocks are arranged as a reading sequence.
Three different checks
A signature, a detector and a risk rule answer different questions.
They are not interchangeable. Each one has a limit, and the page states it.
Implemented and tested Implemented and tested Manipulation detection
“Does this voice recording show signs of AI generation?”
Limit. Probabilistic. Has an inconclusive band. Tested on public data, not on modern zero-shot voice clones or Gulf dialect. Not available for images or video.
Implemented and tested Fraud-risk assessment
“Does this request show pressure, secrecy or payment patterns that call for a pause?”
Limit. Rule-based on the request’s wording and amounts. Indicates risk; it never approves or blocks a payment on its own.
A valid signature shows who signed and that the content has not changed. It does not show that the content is true. Detection identifies warning signs. It is not a guarantee of authenticity, in either direction.
How the business scales
Change the assumptions. See how recurring revenue responds.
The defaults are hypothetical starting points to test, not prices or forecasts. Costs are left blank until they are known, so no margin is implied.
Illustrative result
- Subscription revenue10 institutions × $1,500
- Usage revenue50,000 requests × $0.03
- Total illustrative monthly revenueSubscription + usage
- Illustrative annualised revenueMonthly × 12
No margin is shown. Costs are not yet known. Enter fixed and variable costs to see an illustrative contribution. Those figures would reflect only the costs you enter.
Modelled revenue. It is not existing income, and it is not profit. Tumaini has no paying customers today.
How the same assumptions scale with adoption
| Institutions | Requests a month | Monthly | Annualised |
|---|---|---|---|
| 1 | $1,650 | $19,800 | |
| 5 | $8,250 | $99,000 | |
| 10 | $16,500 | $198,000 | |
| 25 | $41,250 | $495,000 | |
| 50 | $82,500 | $990,000 | |
| 100 | $165,000 | $1,980,000 |
Same per-institution assumptions at each size. Growth in practice depends on pilots, procurement cycles and retention.
Why institutions would adopt it
Built for the moments trust matters most.
Three situations. Each shows what the prototype does today and what would need an institution to integrate.
Banking
A customer receives an urgent payment request that appears to come from a relative or from the bank.
What the prototype does today
- Implemented and testedAnalyses a shared voice note and reports a likely-synthetic, inconclusive or likely-genuine result
- Implemented and testedReads urgency, secrecy and payment wording in English and Arabic to flag risk
- Simulated in prototypeHolds a simulated transfer until a trusted contact confirms it
- Implemented and testedVerifies a signed request against a registered key, for an exact amount and beneficiary
No bank has integrated Tumaini. Integration into a real banking app is a pilot step, not a current capability.
Government
A resident receives an apparently official instruction asking them to share information or make a payment.
What the prototype does today
- Implemented and testedSigns official communications with a registered Ed25519 key, in the institution portal
- Implemented and testedLets anyone verify a signed communication, including through a public verifier
- Implemented and testedCollects impersonation reports in an incident queue for the named organisation
The portal demo uses a fictional authority. No government entity has signed up, and no official endorsement exists.
Digital communications
A user receives a suspicious voice message, image or video and wants to know whether to act on it.
What the prototype does today
- Implemented and testedVoice deepfake analysis, with an inconclusive band and an explanation of uncertainty
- Implemented and testedProvenance checks (C2PA) for images and video, which show whether credentials are present and intact
- Implemented and testedPlain-language safe next steps in English and Arabic
- PlannedImage and video deepfake detection. Not implemented; provenance only.
A missing credential means “unknown”, not “fake”. A valid credential shows origin and integrity, not truth.
Detection is never presented as a guarantee of authenticity. A result of inconclusive means Tumaini does not know, and the next step is to check through another channel.
One trust layer. Many industries.
The same integration pattern applies across four markets.
Tumaini does not need to be the app people open every day. It can become part of the services they already trust.
One well-designed integration can reach every customer of that service. That is why the model scales through institutions, not through individual sign-ups.
No market-size figures are shown. None has been verified against a cited source, and none is needed to read the model.
Financial services
- Where it applies
- Payment requests, new-beneficiary transfers and account-change instructions.
- Integration
- Verification at the moment of payment, inside the bank’s own app.
- Needed first
- A pilot partner, a commercial model licence and UAE-region hosting.
Government services
- Where it applies
- Official notices, fee requests and information requests sent by SMS, email or messaging.
- Integration
- Signed communications that residents can verify through a public verifier.
- Needed first
- An entity’s information-security approval and a registry governance model.
Telecommunications and communication platforms
- Where it applies
- Where scams start: calls, messages and shared media.
- Integration
- A verification step offered to customers at the point they receive suspicious content.
- Needed first
- Platform or operator agreement. Automatic interception is not possible today.
Digital identity and enterprise services
- Where it applies
- Employee and supplier requests, and identity-sensitive account recovery.
- Integration
- Verification of signed requests and impersonation reporting for the enterprise.
- Needed first
- Enterprise pilot. Identity-verification (face or liveness) flows are not implemented.
Differentiation
More than a deepfake classifier.
Detection tools look at a file. Tumaini also connects what it finds to a registered source and to a safer next action.
Detection identifies warning signs. Verification establishes trust where trustworthy evidence exists. Tumaini connects both to safer decisions.
AI-supported manipulation analysis
Detection-only toolCore function
TumainiVoice analysis implemented. Image and video detection not implemented.
Verified-source authenticity
Detection-only toolNot a core function
TumainiSigned communications and requests checked against registered keys.
Protection during sensitive actions
Detection-only toolUsually outside scope
TumainiProtected-action flow, with simulated payments in the prototype.
Plain-language guidance
Detection-only toolVaries
TumainiExplanations and safe next steps in English and Arabic.
Arabic-language support
Detection-only toolVaries
TumainiArabic explanations and request extraction. Voice analysis tested on one Arabic dataset.
Institutional incident response
Detection-only toolUsually outside scope
TumainiIncident queue and verification activity in the institution portal, in prototype.
Embeddable APIs
Detection-only toolVaries
TumainiPublic verification API and sandbox. SDKs planned.
Describes categories of tools, not named competitors. “Varies” means the capability depends on the product.
A human scenario
Trust should not disappear when a voice can be copied.
Illustrative scenario. Not a real incident, and not an endorsement by any organisation.
- 01A mother receives a voice note that sounds like her son. He asks for an urgent transfer to a new account.
- 02Before she sends it, Tumaini analyses the voice note and explains what it can and cannot tell her.
- 03The transfer waits for a trusted contact she registered earlier. The message alone cannot release it.
In the prototype, the analysis is real and the payment and trusted-contact steps are simulated.
From prototype to institutional pilot
A 90-day path to a controlled pilot, if an institution agrees.
Nothing here has been agreed. Days 1 to 30 are about finding out whether an institution wants to test this at all. The full customer pilot follows the 13-week plan once terms are signed.
Days 1–30
Validate
Find out whether one institution wants to test this, and on what terms.
- Confirm one willing institutional pilot owner
- Define one high-risk use case, for example transfers to a new beneficiary
- Review privacy and data requirements, including residency and retention
- Establish baseline metrics from the partner’s own data
- Start the model-licence decision: a commercial licence or an alternative model
- Agree pilot success criteria and rollback triggers in writing
Days 31–60
Integrate
Prove the integration works in a non-production environment.
- Connect one authorised partner workflow in staging
- Test signed communications and supported verification requests end to end
- Measure user comprehension and false alarms with staff volunteers
- Test Arabic and English guidance with native speakers
- Run an accessibility review of the flow
- Review incident-handling procedures with the partner’s security team
Days 61–90
Evaluate
Run a controlled, staff-only pilot in shadow mode, then decide.
- Run shadow mode: Tumaini scores requests, the partner’s existing flow still decides
- Review safety outcomes and false holds against the baseline
- Measure latency, reliability and user understanding
- Assess operating cost per verification with real volumes
- Review the partner’s adoption requirements and approvals
- Decide to expand, revise or stop. A customer rollout would follow the 13-week pilot plan, only once terms are agreed.
Proposed success metrics
These are proposed targets, to be agreed with a partner and validated before use. Where a target is already set in the project’s pilot plan, the source is shown.
Verification response time
Proposed targetp95 under 300 ms for receipt verification; under 10 s for a 30-second voice note
BasisSet in the 13-week pilot plan
Technical availability
Proposed target99.5% during pilot service hours
BasisSet in the 13-week pilot plan
False-positive and false-negative rates
Proposed targetReceipts: 100% of tampered or replayed test receipts rejected. Voice analysis: report measured rates with confidence intervals; no target until the licensed model is re-evaluated.
BasisMeasured on public data; not a guarantee
User comprehension
Proposed targetAt least 80% of surveyed users correctly say what the result meant
BasisSet in the 13-week pilot plan
Safe-action completion
Proposed targetShare of holds where the user cancels or a trusted contact confirms; baseline set in days 31–60
BasisProposed
Institution integration effort
Proposed targetStaging environment reached by week 3 of the pilot plan
BasisMatches the 13-week pilot plan
Cost per verification
Proposed targetMeasured, not targeted, until infrastructure cost is validated
BasisProposed
Incident-report quality
Proposed targetShare of reports with enough detail to triage (channel, time, sender, content evidence); target set in days 31–60
BasisProposed
The detailed outline is on the pilot page.
The business in 25 seconds
Who pays, for what, and why it can repeat.
Tumaini is free where protection matters most: for people. Banks, governments, and digital platforms pay to integrate the verification infrastructure into their services. Through subscriptions and usage-based pricing, every new institutional integration can protect more people, and create a recurring revenue model we will test in the pilot.
- Who pays
- Banks, government entities and digital platforms.
- What they pay for
- Platform access, verification usage and integration support.
- Why it recurs
- Subscriptions renew, and usage grows with the number of checks.
- How it scales
- Each integration protects that institution’s customers wherever it is deployed.