Frequently asked questions

By scheduling debit attempts around a predicted salary window instead of a fixed calendar date, so attempts happen when funds are more likely to be present, and by governing recovery outreach with rules instead of ad hoc agent judgment — notice periods, retry limits, contact frequency caps, and automatic escalation from Collections to Recovery are all enforced consistently rather than depending on any one person remembering the policy.

Every debit is checked against a fixed set of safety invariants — active mandate, amount/date/frequency coverage, notice satisfied, no compliance hold, no duplicate in flight — inside one locked transaction, so a debit can't happen by manual override or a missed check. Every automated action is attributed to a specific rule version and recorded in an append-only audit trail. And role permissions are configurable per your organisation rather than fixed, so who can approve a rule versus who can just view one is something you control.

It's rule-based, not machine learning. The prediction service looks at a customer's recorded salary observations, employer pay cycle, and any customer-confirmed payday, and produces an earliest / most-likely / latest date range with a confidence score and a stated provenance — you can always see exactly what inputs produced a given prediction. An optional scheduler can then attempt a debit automatically within that window, but only for predictions above a confidence threshold; low-confidence predictions are left for manual handling rather than acted on automatically.

We don't publish a blanket accuracy number, and we'd be skeptical of a vendor who did — accuracy depends heavily on how much salary history and employer pattern data exists for a given portfolio. What the system does instead is attach a confidence score and its supporting factors to every prediction, so accuracy is something you can observe and validate against your own portfolio's actual repayment dates, rather than take on faith. A prediction is never presented as a certainty, and low-confidence predictions are excluded from automatic action.

No. Every debit attempt — whether triggered manually or by the automated scheduler — passes through the same eligibility check, and having an active mandate that covers the amount, date, frequency, and account is one of the invariants that must pass before a charge is ever submitted to the payment provider. There is no code path that skips it.

Raising a dispute or hardship case places a compliance hold on that customer that automatically blocks further debit attempts and recovery outreach until the hold is resolved — no manual reminder or separate step required. A customer flagged do-not-contact or wrong-number is excluded from outreach immediately, across every channel and every workflow, not just the one it was flagged in.

CreditPulse is technology and orchestration, informed by FCCPC and CBN guidance — it does not itself constitute legal or regulatory compliance, and that determination rests with your organisation and counsel, not with us. What it provides: mandate-gated debits, quiet-hours and consent-aware contact rules, an append-only audit trail attributing every automated action to a rule version, and a platform that never holds, pools, or settles customer funds directly.

Yes. Collection and contact policies (notice periods, retry limits, quiet hours, frequency caps) are configured per organisation, not hardcoded. Rules go through a draft → simulate → approve → publish lifecycle, with approving and publishing gated by their own permissions distinct from drafting — so one person can propose a rule change and a different person has to approve it. Roles and the permissions attached to them are also editable, so you decide who can do what.

Every automated debit or recovery action is recorded in an append-only audit log, attributed to the actor (system or user), the exact rule and rule version evaluated, and the relevant provider reference — rows are never updated or deleted after the fact. The audit log itself is queryable from within the app for anyone with audit-view access.

All three — SMS and WhatsApp via Africa's Talking, and voice calls via Vapi. Each channel has its own live/mock mode, independently of the others, so you can go live on SMS while voice stays in sandbox, for example. Contact eligibility (quiet hours, frequency caps, do-not-contact) is enforced the same way regardless of channel.

Payment execution is built against a provider-agnostic interface, currently implemented for Flutterwave for mandate authorisation and direct debit. Loans and customers are brought in via CSV bulk import or API sync, which covers most LOS/core-banking export formats without a bespoke connector. We don't ship pre-built connectors for specific CRM or core-banking systems today — for anything beyond the bulk-sync API, that would be a scoped integration conversation, not an out-of-the-box feature, and we'd rather tell you that plainly than imply otherwise.

It depends mainly on how ready your loan and customer data is for import, how many portfolios and custom rules you need configured, and how long your own compliance review of message templates and contact policy takes — that last step is on your timeline, not ours. We don't quote a fixed number of weeks up front because we'd rather scope it against your actual portfolio than give a generic figure that doesn't hold up.

Your lender profile and portfolio details, your loan and customer data (via CSV import), payment provider credentials when you're ready to move off sandbox mode, and someone with authority to define your collection policy, contact policy, and initial roles. We'd also expect your compliance function to review and sign off on message templates before they go live.

Every tenant's data is isolated at both the application query level and the database filter level, and that isolation is covered by dedicated cross-tenant tests, not just assumed. Access within your organisation is governed by roles and the permissions attached to them, which you control. Mandate credentials, call transcripts, and message bodies are excluded from ordinary application logs and masked in API responses by role.

Yes to both. Roles are tenant-defined bundles of permissions — you can edit what a default role like Ops Manager or Compliance Officer is allowed to do, or create custom roles entirely. For maker-checker specifically: rule approval and rule publishing are gated by their own separate permissions from rule drafting, so the person who proposes a change isn't the same permission that ships it. That pattern is currently scoped to the rules engine, not a blanket maker-checker on every action in the system.

A portfolio report with outstanding balance, PAR30/60/90, and an aging breakdown; a collections performance report covering debit attempt success rate and amounts collected over a date range; an agent performance report for recovery case load and resolution; and the audit log itself for compliance oversight. The main dashboard also surfaces live charts — an aging distribution, recovery case status, and a debit-amount calendar — computed from the same underlying data, never placeholder figures.

A failed attempt is recorded with its failure reason, and whether it retries — and how many times, how far apart — is governed by your collection policy, not left to chance. Debit requests, provider webhooks, and imports all carry idempotency keys, so a retried request or a replayed provider event can never double-charge a customer. If a charge is left in a pending state longer than expected, a reconciliation job re-queries the provider for its actual status rather than assuming a timeout means failure.

See our pricing page for plan tiers — every plan is scoped to your portfolio size and regulatory context, and starts with a conversation rather than a credit card.

Regulated Nigerian lenders running mandate-based repayment collections — microfinance banks, digital lenders, finance companies, and cooperatives operating in NGN under CBN/FCCPC oversight. The platform's data model and compliance posture are built around that context specifically, not a generic global lending workflow.

Yes — book a demo and tell us about your portfolio and current process, and we'll walk through a workflow shaped around it rather than a generic script.