Transparency
Methodology
How we measure what we claim. Every number on this site is backed by a defined methodology — no fabricated statistics.
How we choose the rail
FinVeil's routing engine selects a payment rail per transaction using a weighted decision tree. For every authorised request we score every eligible provider (Paystack, Ozow, Visa Direct, PayFast, Yoco) on three axes:
- Cheapest — the effective landed fee after interchange, scheme fees, and provider markup for the amount and method.
- Fastest — the observed P95 settlement time over the trailing 24 hours, per rail, per destination bank.
- Most reliable — the rolling 1-hour authorisation success rate, with automatic failover to the next-best rail on hard decline.
Merchants can override the weighting per transaction via anX-Preferenceheader (cheapest, fastest, or most-reliable) and the engine recomputes the decision before authorisation.
How Transaction Proof works
Every settled transaction is hashed using SHA-256 over a canonicalised metadata envelope (amount, currency, payer, payee, rail, reference, timestamp). The hash is appended as a leaf to the current Merkle batch. Batches are anchored on a public chain at most every 10 minutes, and the resulting root is returned to the merchant alongside the receipt.
Any party with the raw transaction metadata can independently recompute the leaf hash and verify inclusion against the anchored root via the public /verify endpoint. The verifier sees only the metadata the merchant chooses to share — FinVeil does not custody or replay the underlying payment data.
How we match settlements
Reconciliation is a 3-way match across three ledgers, run continuously:
- The provider settlement report (Paystack, Ozow, Visa Direct, etc.)
- The merchant's bank statement (via Stitch / Truelayer / CSV)
- FinVeil's internal transaction ledger
A transaction is reconciled only when all three ledgers agree on amount, date (±1 business day), and reference. Any disagreement is emitted as a typed discrepancy — AMOUNT_MISMATCH,MISSING_PROVIDER_LINE,MISSING_BANK_CREDIT, orDUPLICATE_SETTLEMENT — and surfaced on the Reconciliation dashboard with a suggested remediation action.
Platform uptime
FinVeil targets 99.9% uptime for all production services. Uptime is measured by Railway health checks against the backend API and verified against server logs. Current and historical uptime figures are reported on the Status page.
Legacy product
Wellness Suite methodology (legacy product)
The sections below describe the stress-scoring model that powers FinVeil's Wellness Suite. It is retained for existing Wellness customers; new deployments should start from the payment-orchestration methodology above.
Stress scoring
FinVeil uses a 6-factor rule-based model derived from payroll data to generate employee financial stress scores. Each factor contributes a weighted point value based on empirical indicators of financial distress:
- Presence of garnishee orders
- Loan deductions as a percentage of gross pay
- Net-to-gross pay ratio
- Number of concurrent loan deductions
- Salary band positioning
- Declining net pay trend over 3+ months
Scores range from 0 to 100 and map to four risk levels: Low, Moderate, High, and Critical. Full scoring details are available on the Stress Score product page.
Early-stage transparency
FinVeil is a pre-revenue platform. Pilot deployments and early results will be published here as data accumulates. We do not cite third-party statistics without attribution, and we do not fabricate case-study numbers.