Your data, protected. Your questions, answered straight.
You are trusting us with real information about your institution and your people. We take that seriously. This page answers the questions institutions actually ask us, in plain language, and shows how the platform is protected, layer by layer.
No jargon, no fine print. Just what we actually do, and what we are careful not to over-promise.
The questions institutions ask us
These are the exact questions bank boards, risk teams, and data protection officers put to us. Here are the answers, straight.
Who is responsible for protecting our data: you or the AI companies?
Both, in a chain the law recognises. Your institution stays the owner and controller of its data. LitFin is your processor: we act only on your instructions, under a written data processing agreement. The AI providers we call are our sub-processors: they may use your data only to answer the request. For most of them that limit is an executed data processing agreement. For the inference providers added in August 2026 it is their published business-tier policy, which we have read but have not yet secured in a signed agreement, and our register names them.
The chain is public. Every outside service that ever touches data is on our sub-processor register, and the register records when each one was added and whether the notice period was run before it received data. It was not run for the providers added on 7 August 2026. The register says so rather than hiding it.
Is our data used to train AI models?
No. We never train a shared model on your data, and the AI providers we use do not train on data sent through their business interfaces. For our contracted providers that is a written term of their commercial agreements, not a courtesy. For the inference providers added in August 2026 it is their published business-tier policy, and we say so here rather than imply a contract we have not signed.
We do not rewrite your content before sending it to our AI providers, and that is a deliberate choice. We tried redacting it and it damaged the documents our customers depend on: a bank statement with the lender names removed cannot be reconciled, and an officer's own company history came back with awards and ministries replaced by placeholders. Your document must come back as your document. What protects you is contractual and structural rather than word deletion: most providers work under a data-processing agreement with no-training terms, the registry below names the ones that do not yet, and what the platform learns about your people stays locked to your organisation and to each verified login. Our AI providers operate in several jurisdictions, including China, and the sub-processor registry below names each one.
Are you built on one AI model, or many?
Many, by construction. Every request is routed to the model best suited to the task, across multiple leading AI providers, each wired in live. If one provider fails or degrades, the request automatically falls over to the next, and an unhealthy provider is taken out of rotation until it recovers.
No single company's outage can take the mind away from your team. The same failover discipline runs in our voice and research systems.
What happens when a provider retires or blocks a model?
Model retirements are a normal, planned part of this industry: the major providers publish deprecation policies with advance notice, months in practice. Because LitFin is model-agnostic, a retirement is a routing update on our side, not an outage on yours: the seat that model held is re-pointed to a successor, tested, and switched.
We do not bet the platform on any one company. The routing layer treats every model as a replaceable part, and the strongest providers have publicly committed to long notice periods, and even to preserving retired models.
What agreements stand between LitFin and the AI providers?
Commercial API agreements with data-processing terms: the provider acts as a processor, is barred from using your data for its own purposes, does not train on it, and holds it only briefly for abuse monitoring under published retention limits. These are the same terms the world's regulated industries rely on.
SOC 2 Type II, ISO 27001 and ISO 42001 certifications stand behind parts of the infrastructure we call. We do not claim them for every provider in the chain, because we have not verified them for the providers added during 2026. Our register names every provider, and it is built to give you a notice and objection window before a new one receives your data. That window was not run for the providers added on 7 August 2026: a business decision routed data to them first, and the notice has not been issued. We would rather tell you that here than leave you to find it in the register.
What are the chances of being hacked?
The honest answer: no serious company will tell you zero. What we can show you is the cost an attacker faces: isolation enforced by the database itself for every customer, encryption in transit and at rest with the most sensitive fields individually scrambled, access that is role-checked on every request, rate limits, forged-request rejection, fenced outbound traffic, and a tamper-evident audit log.
And the blast radius is capped by design: this platform physically cannot move money or commit a real lending decision, so the worst day here is not the worst day a bank can have. If a breach affecting personal data ever occurs, Tanzanian law requires notifying the Commission without undue delay, and we will.
How the platform protects data, layer by layer
Walled off from every other customer
Every customer's data sits behind a lock built into the database itself. Even if a piece of our software ever forgot to filter a request, the database still refuses to hand your data to anyone else. Your information is yours alone.
Sensitive details are scrambled before they are stored
Your connection is encrypted, and your data is encrypted while it is stored. The most sensitive fields, like ID numbers and credentials, are individually scrambled with their own key before they ever reach the database, so a stolen record is useless on its own.
Mwikila learns you, and that learning stays yours
Mwikila adapts to your role, your history, and your cases, so the help gets sharper the more you use it. That learning only ever reads and writes your own record, tied to your verified login. Your content reaches the AI model as you wrote it, names and identifiers included, because removing them damaged the documents our customers depend on. What protects you at that boundary is contractual and structural rather than word deletion, and the questions above say plainly which providers have signed an agreement and which have not. We never train a shared model on your data, and nothing you do is visible to another organisation. Managers and administrators see only summaries with names removed.
Only the right people, and only the right pathways, get in
Everyone sees and does only what their role allows, and an automated test blocks any new screen that forgets to check. Requests forged by a malicious website are rejected before they reach your account. And when Mwikila fetches live research from the web, that traffic is fenced off from our internal servers and cloud secrets, closing one of the most common ways attackers try to reach behind a service.
A record that cannot be quietly edited, on a tool that cannot touch real money
Security-relevant actions are written to a chained log where any later tampering is mathematically detectable, and the logs themselves avoid storing personal identifiers. Underneath it all, this is a training and advisory tool by design: the system is built so it physically cannot move money or commit a real lending decision. Mwikila advises, teaches, and explains, and the real call always stays with your people.
We are honest about who processes data
We publish an always-current, machine-checkable list of every outside service that ever touches data, where it runs, and what it can see. The disclosure can never quietly drift from the truth.
You are always in control of your data
Under Tanzania's Personal Data Protection Act, you have real rights over your data, and we have working tools that honour them. You do not have to email anyone or wait for a favour.
- See everything we hold about you
- Take a copy with you in a machine-readable file
- Correct anything that is wrong
- Ask us to delete it, keeping only what the law requires us to retain, with your identity unlinked
These buttons work. Each one files a real request against every system that holds your data, and you get a reference number back.
Straight talk: what we do not claim
We would rather be honest than oversell. Trust is built on the things a company is careful not to say. Here is where we draw the line.
- We do not claim certifications we have not earned. Our controls are designed around recognised security principles, and we will tell you plainly when a formal certification is in progress rather than complete.
- We do not say 'unbreakable'. No honest company can promise that. What we can do is protect your data in layers and show you exactly what each layer does, which is what this page is.
- Your conversations are encrypted on the way to us and while they are stored, but they are not end-to-end encrypted: we process them on our servers to do the work, after masking your personal details. We say 'encrypted', never 'end-to-end', because the difference matters.
- Some AI processing happens outside East Africa. We do not pretend all your data stays in one country. Every place data is processed is disclosed on our data-transfers page, under legal safeguards.
- Two-factor sign-in is not live yet. Access today is protected by organisation-issued credentials, role-based permissions, and session controls; two-factor authentication is on our security roadmap, and this page will say so when it ships.
- Tanzania's data-protection law runs a registration and transfer-permit regime through the Personal Data Protection Commission. We track those obligations with our advisers, and we will show any institution, in writing, exactly where we stand rather than print a badge here.
The legal bar in Tanzania, and how we hold it
Tanzania's Personal Data Protection Act (2022) and its 2023 regulations set a real, enforced bar. Here is what the law requires of a platform like this, in plain language, and what we run to meet it.
What the law requires
- Registration of data controllers and processors with the Personal Data Protection Commission, on a certificate renewed every five years
- A named data protection officer
- A written contract governing every processor relationship
- Security safeguards proportionate to the data, and breach notification to the Commission without undue delay
- Restricted cross-border transfers: personal data leaves Tanzania only under the Act's conditions and the Commission's permit regime
What we run
- A data processing agreement offered to every institution, with the controller and processor roles stated plainly
- Working rights tools: access, export, objection, and deletion requests are automated on this page, not an email queue
- A public register of every sub-processor, and a disclosure page for every cross-border transfer
- A data protection officer you can reach directly, and written evidence of our compliance posture for any institution that asks
If you are a bank or financial institution, your own regulator's outsourcing and cloud rules apply to your use of any platform, including this one. Our documentation, customer isolation, and breach-disclosure commitments are built to stand that due diligence, and we will support your approval process with the Bank of Tanzania.
Questions about your data? Our Data Protection Officer is at dpo@litfin-training.com