What we do with your cheque data — and what we cannot do with it
This page is written for the people who have to sign off on us: risk, security and compliance. It states what is implemented today, what is not yet, and what we will answer in writing.
- Funds access
- None
- Decision authority
- Your reviewer
- Data owner
- Your institution
Scope boundary
MobiCheque never touches money
The platform captures a cheque, extracts its fields, runs verification checks and routes the case to a reviewer. It holds no accounts, connects to no payment rail, and has no mechanism to release funds. Every clearing and settlement action stays inside your existing process.
What is in place today
The controls below are implemented and can be demonstrated during a technical review.
Encryption in transit and at rest
All traffic between the mobile app, the API and the console runs over TLS. Cheque images and extracted data are encrypted at rest in storage.
Role-based access control
Console access is scoped by role. Reviewers, administrators and support staff see only what their role permits, and access is granted per institution.
Attributable audit trail
Every action on a cheque — capture, extraction, each check, each decision — is timestamped and attributed to an identity. The trail is append-only.
Duplicate and replay protection
Submissions are matched against cheque history before reaching a reviewer, so the same instrument cannot be presented twice through the platform.
Human decision authority
MobiCheque never clears, settles or releases funds. It gathers evidence and routes to your reviewer, who holds the decision.
Retention and deletion
Retention windows are configurable per institution, with defined deletion on expiry and on contract exit.
Exactly what we process
No category of data beyond this list is collected or retained by the platform.
| Category | What it contains | Why we hold it |
|---|---|---|
| Cheque image | Front and back capture of the physical instrument | Source for extraction and reviewer verification |
| Extracted fields | Payee, amount, cheque number, date, drawer bank | Verification checks and reviewer decisioning |
| Submitter identity | Name, contact details, institution linkage | Attribution and status notification |
| Decision record | Reviewer identity, action taken, timestamp, rationale | Audit trail and dispute resolution |
| Technical logs | Access logs, API calls, error traces | Security monitoring and incident investigation |
What we have, and what we do not have yet
We would rather tell you now than have you discover it in diligence. This list is kept current.
Encryption, access control and audit logging
In placeImplemented across the platform today.
Human review on every cheque
In placeNo cheque is auto-approved. A reviewer in your institution decides.
Independent penetration test
Not yetNot yet completed. We will publish the summary report and remediation status once it is.
ISO 27001 / SOC 2
Not yetNot currently certified. We are happy to complete your vendor security questionnaire in the meantime.
Data Protection Act registration
Not yetRegistration status with the Office of the Data Protection Commissioner — confirm current position before publishing.
Answers before you send the questionnaire
The questions institutional security teams ask us most often, answered in advance.
Does MobiCheque hold, move or settle funds?
No. MobiCheque is a capture and verification layer. It has no access to accounts, no payment rails, and no ability to move value. Clearing and settlement remain entirely within your institution and its existing arrangements.
Who owns the data?
The institution. MobiCheque processes cheque data on your behalf under contract. You can export your records, and data is deleted on exit according to the agreed schedule.
Where is data hosted?
Confirm before publishing — state the hosting provider and region. Kenyan institutions increasingly require in-country residency, so answer this explicitly rather than generically.
Can MobiCheque staff see our cheque data?
Access is restricted to what is required for support and incident response, is logged, and is granted on a least-privilege basis. Define and document your internal access policy here.
What happens during an incident?
Document your incident response process: detection, containment, your notification commitment and timeline to affected institutions, and post-incident reporting.
How do we exit?
Records are exportable in a structured format. On termination, data is returned or deleted per the contract, with written confirmation of deletion.
Is the platform penetration tested?
Not yet independently tested. State the planned date and the scope once scheduled.
What are the availability commitments?
Define your target uptime, maintenance windows, support hours and escalation path before signing an institutional agreement.
Need this in your own format?
Send us your vendor security questionnaire and we will complete it and return it with supporting detail.