Skip to content
Timothy AdebayoProduct Designer AI Native Designer
FRI, SEP 25, 2026
Send a Message

Dedukt Pay

Closing the reconciliation gap behind loan defaults — built in two weeks to replace a disconnected third-party tool with something native to Dedukt's own data.

My RoleProduct Design Consultant — led product and interaction design
TeamProduct Designer (me), 1 Fullstack Engineer, 1 PM
Duration2 weeks
IndustryFintech

OVERVIEW

Dedukt sits as the middleman between lenders and employers on every loan it processes, which means when repayment reconciliation breaks down, Dedukt absorbs the consequences directly: employees defaulting, lenders not getting paid on time. An existing third-party tool handled reconciliation before this, but it sat outside Dedukt's own ecosystem, disconnected from the source, employer, and lender data Dedukt actually manages. Dedukt Pay was built in two weeks to replace it with something native, and default rates have dropped by over 85% since.

THE PROBLEM

Reconciliation wasn't unhandled before Dedukt Pay, it ran through a third-party tool. But that tool sat outside Dedukt's own ecosystem, disconnected from the actual source, employer, and lender records Dedukt manages, which made it slow and error-prone rather than just imperfect. That had real consequences, not bookkeeping ones: employees defaulting on loans, and lenders not getting paid back on time, a serious problem for a company whose entire pitch to lenders rests on reliable collection.

THE PROCESS

Replaced an outside tool with something native to the ecosystem.

Rather than patch the third-party tool, Dedukt Pay was built to sit inside Dedukt's own data model, so source, employer, and lender records are the same records the reconciliation logic runs against, not a separate system that has to be kept in sync.

Split "actual," "receivable," and "final" deduction into distinct fields.

A default or a late payment usually starts as a gap between what should have happened and what did. Making that gap visible as its own number, instead of one blended total, is what lets a discrepancy get caught early instead of surfacing as a default months later.

Tied reconciliation directly to employment status.

An employee going suspended zeroes out their receivable and final deduction automatically. One of the most common causes of missed collection, a payroll change nobody flagged downstream, gets caught by the system instead of relying on someone noticing.

Gated disbursement behind account status, not initiation.

A lender record only becomes actionable once its account status flips from Insufficient to Sufficient Balance, protecting "lenders get paid on time" from the other direction, nothing disburses against money that isn't confirmed.

Shipped in two weeks by settling the data logic first, navigation second.

The actual/receivable/final split and the disbursement gating had to be right immediately, this was replacing a live tool tied to real defaults and real lender payments. The IA, Source Management, Transaction Log, Audit Log, locked in once that logic held.

SOLUTION

  • Actual / Receivable / Final Deduction as separate columns, per employee-lender pair, so a mismatch is legible in the row itself instead of something that has to be investigated.
  • Disbursement gated by account status. Pending and disbursable records live in separate tabs, so nothing moves against unconfirmed money.
  • A details view that explains the gap, not just states it. Opening a record surfaces loan terms, tenor, and employment status together, so a ₦0.00 receivable on a suspended employee reads as explained, not broken.
  • Source and account management as its own layer, tracking virtual and physical accounts per source and employer, so money can be traced to exactly which account it should have moved through.

OUTCOME

Default rate has dropped by over 85%

Since launch, directly against the core problem this was built to solve.

Lenders are getting paid on time

Closing the other half of the original complaint.

Operationally

Reconciliation is faster and more accurate, disputes are down, and month-end close is quicker than it was under the old tool.

Before

Frequent record mismatches and no accurate, trustworthy record of who had actually defaulted, meaning even knowing the scale of the problem was hard, not just fixing it.

REFLECTION

The real pressure wasn't the reconciliation logic itself, it was replacing a live tool that was actively contributing to defaults, in two weeks, with no room for a soft launch. Every day the old system stayed in place was another day of employees defaulting and lenders waiting on payment, so the actual/receivable/final split and the employment-status tie-in had to work correctly on first release, not get refined after.

Given the 85% drop, that bet held. If I did this again, I'd want a way to distinguish genuine defaults (an employee who simply can't pay) from reconciliation gaps that slipped through, since right now the dashboard shows the outcome, a default, without showing why, which is the same kind of ambiguity Dedukt Pay was built to remove everywhere else.

RELATED WORKS

See more