MiProof Agent Privacy Policy

Effective date: 28 April 2026
App: MiProof Agent (Android package com.mikashboks.verify.agent; iOS bundle com.mikashboks.verify.agent)
Publisher: MiKashBoks
Applies to: The MiProof Agent mobile application only. For the consumer MiKashBoks app and the mikashboks.com website, see the main MiKashBoks Privacy Policy.

MiProof Agent is a field-agent companion app used by authorised MiKashBoks agents to onboard customers for regulated financial services. Agents use it to take photos of a customer's identity document, take a live selfie of the customer for face matching, capture proof-of-address evidence, and submit those captures to the MiKashBoks Identity Verification platform for review.

This notice tells you, in plain language, what data the app collects, why each device permission is needed, who we share data with, and how long we keep it. It is written to comply with the Google Play Developer Program Policies (including the User Data, Permissions and APIs that Access Sensitive Information, and Photo and Video Permissions policies), the EU General Data Protection Regulation (GDPR) where it applies, the California Consumer Privacy Act / CPRA, and the data-protection laws of the West African markets we operate in.

1. About MiProof Agent

In short: MiProof Agent is used by authorised field agents to verify the identity of customers (KYC) and businesses (KYB) on behalf of MiKashBoks and our partner financial institutions. There are two groups of people whose data flows through this app: agents (the app's users) and the customers they onboard.

The app's job is narrow and specific. An authorised agent uses it to:

Take a clear photo of a customer's identity document (for example, a Sierra Leone National ID, ECOWAS Card, Passport, Voter ID, or Driver's Licence).
Take a live selfie of the customer so we can match the face on the document with the person in front of the agent.
Where the workflow requires it, capture business-registration documents and proof-of-address evidence (a typed address, or a photo of the customer's front door together with a GPS reading).
Submit those captures to the MiKashBoks Identity Verification backend, where they are checked by our verification engine and (where required) by a human reviewer.

This policy distinguishes between two roles:

Agent — the person logged into the app. Their data is limited to what is needed to authenticate them and to attribute captures to them (phone number, biometric unlock, device fingerprint, capture location).
Customer — the person or business being onboarded. The captured ID images, selfie, and declared personal details belong to the customer; agents capture them on behalf of MiKashBoks and the partner institution.

2. What we collect

In short: Identity documents, a selfie, the customer's typed details, the agent's login credentials, and basic device and capture-location data. That is the entire list.

Category	Examples	Source
Identity document images	Photo of a National ID, Passport, Voter ID, Driver's Licence, Business Registration Certificate, Market Association card, or mobile-money statement	Captured by the agent using the in-app camera
Selfie / face image	A single live photo of the customer's face, used for one-to-one face match against the ID photo and to detect duplicate enrolments	Captured by the agent using the in-app camera
Personal details	Customer's first and last name, date of birth, gender, nationality, ID number, phone number, email address, residential address; for KYB, business name and registration number	Typed by the agent or extracted from the document image by our backend verification engine
Capture location	GPS latitude, longitude, and accuracy taken at the moment of capture (and at the proof-of-address step where applicable)	Device GPS, only when the agent is on a capture or address-proof screen and grants location permission
Agent account data	Agent phone number, agent ID, hashed password, biometric-unlock refresh token (kept only on-device in the secure enclave / Android Keystore)	Provided by the agent at sign-in
Device and technical data	Device model, OS version, app version, language, IP address, time zone, network type, anonymised crash logs, push-notification token	Automatically, when the app is in use
Workflow logs	Events such as “capture started”, “capture retaken”, “submitted”, plus error codes and quality metrics, attributed to the agent and the case	Generated automatically for audit and quality assurance

3. What we do not collect

For clarity, MiProof Agent does not collect or access:

Your contacts, calendar, SMS messages, or call logs.
Your photo or video library (see section 5 — we use the system Photo Picker only for one-time, user-selected files, not your library).
Audio recordings, voice notes, or microphone input. The app does not record audio.
Files outside the single image the agent explicitly picks via the system Photo Picker.
Your browsing history or installed-app inventory.
Advertising identifiers. MiProof Agent shows no advertising and does no advertising-related profiling.
Any data captured by the consumer MiKashBoks app or by the MiKashBoks website. Those are governed by a separate policy.

4. Device permissions, one by one

In short: Each permission below maps to a specific capture step. We ask for it at the moment that step is reached, not on first launch, and we do not use any permission for advertising, profiling, or analytics.

Camera

Camera `android.permission.CAMERA` · iOS `NSCameraUsageDescription`

This is the core permission of the app. Without it, MiProof Agent cannot do its job.

What we do:Open a live camera preview so the agent can take a photo of the customer's identity document and a live selfie of the customer.

Why we need it:The whole purpose of the app is to capture verifiable photos of identity documents and the customer's face. There is no alternative way to do this.

When we ask:The first time the agent reaches a document-capture or selfie-capture screen.

What we don't do:We do not record video, we do not stream the camera anywhere, and we do not run the camera in the background.

Location

Location `ACCESS_FINE_LOCATION` / `ACCESS_COARSE_LOCATION` · iOS `NSLocationWhenInUseUsageDescription`

What we do:Read the device GPS to attach a latitude/longitude to a capture, so the partner institution can confirm the visit happened in their service area, and to record the location of a proof-of-address front-door photo.

Why we need it:Banking regulators require auditable evidence that a field agent actually visited the customer. The GPS reading is part of that audit trail.

When we ask:Only on capture and proof-of-address screens. Never in the background. We use “while-using-the-app” precision and never “always”.

What we don't do:We do not track the agent's movement between captures, we do not draw maps of agent routes, and we do not share location with advertisers.

Notifications

Notifications `android.permission.POST_NOTIFICATIONS`

What we do:Show messages from the workflow on the agent-workflow-updates notification channel — for example, “Case ready for review”, “Retake required”, or “Submission accepted”.

Why we need it:Field agents are often offline when a backend reviewer asks them to retake a photo or returns a decision. Notifications are how they find out without polling the app.

When we ask:On first launch on Android 13+, where this is a runtime permission. The agent can decline and continue using the app.

What we don't do:We do not send marketing notifications, and we do not include personal data of the customer in notification text.

Biometric

Biometric unlock `USE_BIOMETRIC` / `USE_FINGERPRINT` · iOS `NSFaceIDUsageDescription`

What we do:Let the agent unlock the app with the same fingerprint or Face ID they use to unlock their phone, instead of typing their password each time.

Why we need it:Agents log in dozens of times a day. Biometric unlock is faster and reduces password fatigue, which means fewer weak passwords. The OS performs the match on-device; the biometric template never leaves the phone.

When we ask:When the agent enables biometric unlock from the sign-in or settings screen.

What we don't do:We do not see, copy, or upload the agent's fingerprint or face template. We only receive a yes/no result from the operating system.

Internet

Internet `android.permission.INTERNET`

What we do:Submit captures to the MiKashBoks backend, fetch the customer's case, receive workflow updates, and check for app updates.

Why we need it:The app is useless without a way to send captures to the backend.

When we ask:Always — this is granted automatically at install on Android. We do work offline where we can: captures are queued on-device and submitted as soon as connectivity returns.

Vibrate

Vibration `android.permission.VIBRATE`

What we do:Give a small haptic tap when an ID document is correctly framed in the capture window or when an action succeeds.

Why we need it:Haptics help agents capture a usable photo on the first try, which means fewer retakes for the customer.

When we ask:Granted automatically at install — no runtime prompt.

Overlay

Capture overlay `android.permission.SYSTEM_ALERT_WINDOW`

What we do:Draw the framing guides, glare warnings, and quality hints over the camera preview while the agent is taking a photo.

Why we need it:Real-time guidance dramatically improves capture quality, which reduces retakes and false rejections at the verification step.

When we ask:Only on capture screens.

Legacy storage

Read external storage (Android 12 and below only) `READ_EXTERNAL_STORAGE` with `maxSdkVersion="32"`

What we do:On Android 12 and below, this is requested only when the agent taps “Choose existing photo” as a one-time fallback when the camera is unavailable.

Why we need it:Older Android versions do not yet have the system Photo Picker, so this is the only way to let an agent attach an already-captured ID photo.

When we ask:Only on Android 12 (API 32) or below, and only when the agent explicitly taps the gallery fallback. Not requested on Android 13 or newer.

What we don't do:We do not read, scan, index, or upload anything other than the single image the agent picks.

5. Photo and Video files (Google Play Photo and Video Permissions policy)

In short: MiProof Agent does not request READ_MEDIA_IMAGES or READ_MEDIA_VIDEO. On Android 13 and above, when an agent needs to attach an existing photo of an ID document, MiProof Agent uses the Android system Photo Picker, which gives the app one-time access to only the single file the agent picks.

The core purpose of MiProof Agent is to capture new evidence using the device camera. We do not need broad or persistent access to a device's photo library, and we have built the app accordingly.

How MiProof Agent handles photos and videos

The default capture path is camera-only. When an agent reaches a document or selfie step, the app opens the live camera. No media-library permission is required for this path.
The optional “Choose existing photo” fallback uses the Android system Photo Picker on Android 13+. The Photo Picker is a system UI; MiProof Agent never sees the agent's broader library, only the single file they pick. The app does not declare or request READ_MEDIA_IMAGES or READ_MEDIA_VIDEO.
On Android 12 and below, the legacy READ_EXTERNAL_STORAGE permission is used only for the same one-time picker fallback, and is declared with android:maxSdkVersion="32" so it is automatically not requested on newer devices.
No background or bulk access. MiProof Agent never scans, indexes, hashes, uploads, or reads photos in the background. Each picker selection is an explicit, foreground action by the agent.
No video. MiProof Agent does not record, capture, or read video files.

If you ever see MiProof Agent ask for a permission that does not match a step you are on, please stop and contact us using the details in section 16 — that would be a bug, and we want to fix it.

6. How we use information

In short: To verify identities for regulated financial services, prevent fraud, and meet our legal obligations — nothing else. We do not sell personal information and we do not use it for advertising.

We use the information described above to:

Run identity and business verification. Compare the captured ID against the live selfie, run document-authenticity checks (OCR, MRZ parsing, security-feature analysis), and route results to the partner institution's case-management dashboard.
Prevent fraud. Run face de-duplication so the same face cannot be enrolled under multiple identities, and detect screen-recapture, deep-fake and template attacks.
Operate and improve the app. Authenticate agents, route workflows, resume interrupted captures, deliver workflow notifications, fix bugs, and analyse aggregate quality metrics (for example, capture-failure rates per device model).
Maintain audit trails. Record who captured what, when, and where, so MiKashBoks and our partners can demonstrate to their regulators that field captures genuinely happened.
Comply with legal obligations. Including the Sierra Leone Anti-Money Laundering and Combating of Financing of Terrorism Act, Bank of Sierra Leone customer-due-diligence rules, and equivalent rules in the other markets we operate in.

We do not use captured data for advertising, behavioural profiling, training third-party generative-AI models, or any purpose unrelated to identity verification.

7. Legal bases

Where the GDPR or a comparable data-protection law applies, we rely on the following legal bases:

Contract — performing the verification service that MiKashBoks (or a partner institution) has been engaged to provide.
Legal obligation — meeting customer-due-diligence (KYC), AML/CFT and sanctions-screening obligations.
Legitimate interests — preventing fraud, securing the app, and maintaining audit logs. Where we rely on this basis we balance it against your rights and interests.
Consent — for biometric processing where local law requires explicit consent. The customer being onboarded is asked to consent before a selfie or facial template is created.

In short: The partner financial institution that engaged us, the regulators they are accountable to, and a small set of technical service providers (listed in section 9). We do not sell personal information.

The partner financial institution that engaged MiKashBoks to verify the customer (the “tenant”). They are the joint or independent controller of the captured customer data.
Regulators and law enforcement, where we are legally required to disclose information — for example, the Financial Intelligence Unit, the Bank of Sierra Leone, or a court of competent jurisdiction.
Technical service providers that host or process the data on our behalf under written data-processing agreements (see section 9).
Successor entities in the event of a merger, acquisition or asset sale, subject to the new entity honouring this policy.

MiKashBoks does not sell, rent, or trade personal information. We do not share captured data with advertisers, data brokers, or third-party analytics services.

9. Service providers

The MiProof Agent app relies on the following service providers to deliver the verification workflow. They process data on our behalf, under written data-processing agreements, and are not permitted to use it for their own purposes.

Provider	Role	Region
Google Cloud Platform — Cloud Run, Cloud SQL, Artifact Registry, Secret Manager	Hosts the verification backend that receives captures from MiProof Agent and stores them encrypted at rest.	europe-west1 (Belgium)
Google Cloud Document AI & Vision API	Performs OCR and structured extraction on captured ID document images.	EU multi-region
Google Genkit / Gemini models (enterprise terms)	Performs document classification and field-level validation. Inputs and outputs are not used to train Google's foundation models.	EU / global, per Google's enterprise terms
Firebase Cloud Messaging	Delivers push notifications for workflow updates to the MiProof Agent app.	Global
Expo / EAS	Application build and over-the-air JavaScript update delivery. Does not receive captured customer data.	United States

We keep this list current. If we add a service provider that handles personal data on our behalf, we will update this section before they go live. Verifications may also be checked against external records (for example, national ID registries or business registries) by the partner institution; that processing is described in the main MiKashBoks Privacy Policy and in the partner's own customer-facing notice.

10. How long we keep information

In short: Captured customer data is kept for as long as the partner institution must keep it under applicable AML / KYC law — typically five to seven years — then deleted or fully anonymised. Agent device telemetry and crash logs are kept for up to 90 days.

Captured ID images and selfies: retained for the period required by the partner institution's KYC / AML obligations (typically 5–7 years from the end of the customer relationship under Sierra Leone AML/CFT rules).
Facial templates (vector embeddings): retained for the same period to enable de-duplication. We never store raw face images on the bio-facial service — only mathematical embeddings.
Workflow audit logs: retained for the period required by the partner institution's audit policy (typically 7 years).
Agent device telemetry / crash logs: up to 90 days.
Push-notification tokens: until the agent uninstalls the app or signs out.
On-device data: draft captures, the agent's biometric refresh token, and offline queue items live only on the agent's device, in the OS secure enclave (Android Keystore / iOS Keychain). They are wiped on sign-out, on app uninstall, and after the configurable idle-session timeout.

11. Security

Encryption in transit with TLS 1.2+ for every network call, including service-to-service calls inside Google Cloud.
Encryption at rest using Google-managed keys for Cloud Run, Cloud SQL, and Artifact Registry, with selected secrets in Google Secret Manager.
Service-to-service authentication using Google-issued IAM identity tokens between backend services.
Tenant isolation — every request is scoped to a tenant ID and project ID, and downstream services enforce that scope.
HMAC-signed callbacks on all backend-to-backend webhooks (SHA-256).
Hardware-backed credential storage on the device (Android Keystore / iOS Secure Enclave) for the agent's refresh token and biometric session.
Idle session lock — agents are required to re-authenticate after a period of inactivity.
Least-privilege access for MiKashBoks operators, with audit logging on all administrative actions.

No system is perfectly secure. If you become aware of a vulnerability or a possible incident affecting MiProof Agent, please report it to security@mikashboks.com.

12. Minors

The MiProof Agent app itself is not intended for use by anyone under 18. Only authorised, adult field agents may install and use it.

MiProof Agent may, however, capture identity data about a minor where a parent or legal guardian is present and the minor is being onboarded into a permitted, regulator-approved financial-inclusion programme (for example a youth-savings product). In those cases the parent or guardian must be physically present, must consent to the capture on the minor's behalf, and is the person to whom we communicate any privacy rights or notices. If you believe MiProof Agent has captured data about a minor outside of those circumstances, please contact us using the details in section 16 and we will delete the relevant records.

13. Your rights

Subject to the law that applies to you, you may have the right to:

Request a copy of the personal information we hold about you.
Ask us to correct inaccurate information.
Ask us to delete your information, subject to overriding legal-retention obligations (KYC / AML records cannot be deleted before the regulatory retention period ends).
Object to, or request a restriction of, processing.
Withdraw a consent you previously gave (where we relied on consent).
Lodge a complaint with the data-protection authority in your country.

Because most of the data captured through MiProof Agent belongs to a customer of one of our partner financial institutions, the partner is usually the primary point of contact for rights requests. If you contact MiKashBoks directly, we will route your request to the right partner and respond to you within 30 days.

14. California (CCPA / CPRA) notice

If you are a California resident, the California Consumer Privacy Act, as amended by the California Privacy Rights Act, gives you specific rights regarding your personal information. The categories of personal information described in section 2 above are the categories MiProof Agent may collect about you. We do not sell personal information, we do not share it for cross-context behavioural advertising, and we have not done so in the preceding 12 months.

To exercise a California right, email legal@mikashboks.com with the subject line “California Privacy Request”. We will verify your identity before responding.

15. Updates

We may update this notice from time to time. The “Effective date” at the top of this page tells you when it was last revised. When changes are material, we will surface a notice in the app on next sign-in and, where required, request fresh consent. The most current version is always at https://mikashboks.com/agent-privacy-policy/.

16. Contact

Privacy and data-protection questions: privacy@mikashboks.com
Security incidents: security@mikashboks.com
General legal: legal@mikashboks.com
Postal address: MiKashBoks, 69 Gray Street, Arlington, MA 02476, United States.

© 2026 MiKashBoks. MiProof and MiProof Agent are trademarks of MiKashBoks. This notice supplements, and does not replace, the main MiKashBoks Privacy Policy and the partner institution's own customer-facing privacy notice.