01 · Overview
Making Muawin's credit infrastructure available to other companies.
Muawin had proven its micro-lending model: field agents, small loans to retail store owners, cash collection. But the next growth lever was not more agents or more stores, it was making Muawin's credit infrastructure available to other companies.
The idea
A partner company (a grocery delivery app, a ride-hailing service) could embed lending inside their own product. Their users would apply for credit without ever leaving the partner's app. The request would hit Muawin's API, get approved or flagged for review, and the money would move. The end user would never know Muawin existed.
I designed the product from the ground up: the API contract that partners integrated against, the approval logic that determined what the system could handle automatically versus what needed a human, and the internal portal where our team reviewed edge cases. Within four months of launch, this product accounted for 40% of company revenue and processed 30,000+ transactions per month.
02 · The Problem
What does product design look like when the product is invisible?
This was not a consumer app redesign. There were no onboarding flows to polish or button colors to debate. The end user would never see a Muawin screen. They would apply for credit inside an app they already used, and either get approved or not.
The design challenge lived at a different layer entirely: the system between systems and employees interfacing with our own system.
Three tensions that couldn't all win at once
Partner simplicity vs. credit data quality
Partners wanted a simple integration: send a name, a phone number, maybe an ID, and get a yes/no back. But lending responsibly requires signal: the less data we required, the worse our credit decisions would be. The more we required, the fewer partners would bother integrating.
Approval speed vs. default risk
End users expected near-instant decisions. They are in the middle of ordering supplies or fueling up; they will not wait a full day for a credit answer. But faster approvals with less scrutiny meant higher default rates.
Backlog throughput vs. review quality
Not every case could be auto-approved. Some needed a human. But every case sitting in a "needs review" queue was a real person waiting inside a partner's app. If the review queue backed up past our same-day SLA, the partner experience broke, and partners would lose trust in the product.
The Core Insight: The product was not a single design problem. It was three interlocked ones. The API contract affected what the approval engine could automate. The automation rate affected how much volume hit the review queue. The review queue's throughput affected whether partners could trust the SLA. Every design decision rippled across the whole system.
03 · System Design & The API Contract
The architecture is the design artifact.
In a consumer product, the deliverable is screens. In an infrastructure product, the deliverable is the system itself: how data flows, where decisions happen, and who (or what) makes them.
Unlike a typical fintech product with a lender and a borrower, this product had three parties: the partner (whose app the user was in), the end user (who was borrowing), and Muawin (who was lending). Designing the contracts between these three parties (what data moves where, who sees what, who is responsible for what) was the foundational design work.
The core flow
- 1
Partner app
End user applies for credit inside the partner's interface. Partner collects the required data and sends it to Muawin's API.
- 2
Muawin API
Receives the request, validates the payload, runs it through the credit scoring engine.
- 3
Approval engine
Three outcomes: auto-approve (clear cases), auto-deny (obvious disqualifications), or route to needs-review (everything in between).
- 4
Disbursement
Approved requests trigger an automatic transfer to the end user, or in later integrations, directly to a supplier on the user's behalf.
- 5
Repayment
Collection through the partner's existing payment rails or Muawin's own infrastructure.
The first integration: a major grocery delivery app
The grocery delivery app was our first partner. Their users (store owners who sold goods through the platform) could apply for working capital directly inside the app. Repayments would be deducted from their future delivery earnings.
The central product design question: what data fields does the API require from partners?
Every required field served two masters. For the credit engine, more data meant better decisions, fewer defaults, and more confident auto-approvals. For the partner's engineering team, every required field was integration friction: more data to collect, more edge cases to handle, more reasons to deprioritize the integration.
The design decisions
Mandatory fields kept to the minimum
Identity verification (national ID), basic financial signal (transaction history on the partner platform), and contact information. These were fields the partner already had, so integration cost was low.
Optional fields improved the model
Employment details, other income sources, tenure on the platform. When partners sent these, auto-approval rates improved. When they did not, the system still worked but routed more cases to human review.
The API was designed to get smarter
As we processed more applications from a partner, the model learned which signals mattered for that partner's user base. Early integrations had more manual review; mature integrations were mostly automated.
Product Tradeoff — Simplicity vs. signal: An early version of the API required significantly more fields to ensure high auto-approval rates from day one. Partner feedback during the grocery integration was clear: they would integrate a 5-field API this quarter, or a 15-field API never. The tiered mandatory/optional approach was the compromise. Ship fast with fewer requirements, then improve accuracy over time as partners opted into sending more data.
04 · The Automation Line
Where to put the human in the loop.
The approval engine had to answer one question for every incoming request: can the system decide this, or does a person need to look at it?
Getting this wrong in either direction had real consequences. Auto-approve too aggressively, and default rates climb. Route too many cases to manual review, and the queue backs up, end users wait, and the same-day SLA breaks.
Three buckets, one threshold to tune
The system used a scoring model that placed every application into one of three buckets.
Auto-approve
High-confidence cases where the data clearly supported approval. These moved through in seconds with no human involvement.
Auto-deny
Cases that failed hard criteria (sanctions list, identity verification failure, outstanding defaults). Instant, no ambiguity.
Needs review
Everything in between. The score was inconclusive, or specific flags were triggered (unusual loan amount for the partner's typical range, new user with limited history, conflicting data points). These were routed to the internal review portal.
The design of the thresholds (where auto-approve ended and needs-review began) was the single most consequential product decision. A conservative threshold meant more cases in the review queue: safer, but slower. An aggressive threshold meant faster approvals but more risk.
Product Tradeoff — Speed vs. safety: The initial threshold was conservative, with roughly 60% of cases auto-decided and 40% going to review. As the model learned from reviewed cases and we gathered more data on what actually predicted repayment, the auto-approval rate climbed. The design was not to set the threshold once. It was to build a system where the threshold could move as confidence improved.
05 · The Needs-Review Portal
The 10-minute review that took all day to reach.
Once a reviewer actually opened a case, the review itself was fast, about 10 minutes on average. The problem was never the individual review. It was the queue.
Cases arrived throughout the day. Reviewers had other responsibilities. By mid-afternoon, dozens of cases could be waiting, each representing a real person inside a partner's app expecting an answer. If the queue was not cleared by end of day, the same-day SLA broke.
The portal had to solve three things simultaneously: get the right signal from noisy data so reviewers could orient in seconds, maximizing queue velocity so cases did not pile up, and ensuring decision consistency so different reviewers made similar calls on similar cases.
Design decisions
Four decisions that compressed a 10-minute review into a confident, queue-aware action.
Critical signals pinned at the top
The score, the specific flags that triggered review, and the AML check result were always visible without scrolling. Everything else was available below the fold but did not compete for attention.
Flag-first case presentation
Instead of showing a generic applicant profile, each case led with why it was flagged. If the trigger was an unusual loan amount, that was the first thing the reviewer saw, with the relevant context (partner's typical range, applicant's history) right next to it.
Queue-optimized workflow
After resolving a case, the next case loaded automatically. The approve/deny action was a single interaction. Session stats (cases reviewed, cases remaining, time to SLA cutoff) were visible so reviewers could self-pace against the 4pm target.
Integrated AML screening
Each case ran through sanctions and regulatory database checks automatically. The result was surfaced as a simple pass/flag indicator, not a raw data dump.
Product Tradeoff — Depth vs. speed: An early design gave reviewers full access to every data point in an expandable profile. Reviewers consistently said they only needed 3 or 4 signals to make a decision, but the comprehensive view made them feel obligated to check everything, which slowed them down. The redesigned portal made the critical signals prominent and the rest accessible but not demanding of attention. Reviewers felt confident making faster decisions because the interface told them what to focus on.
06 · Scaling: The Uber + Shell Integration
Same infrastructure, completely different product.
The grocery integration proved the model worked. But the second major integration, connecting Uber and Shell, proved the infrastructure could flex into a fundamentally different product form.
The grocery integration was cash credit: a user borrows money, Muawin disburses, the user repays over time. The Uber + Shell integration was in-kind fuel credit. Uber drivers needed fuel to work. Muawin assessed their creditworthiness using data from both Uber (ride history, earnings, activity) and Shell (account status), then routed a request to Shell to top up the driver's fuel card. The driver never received cash. They received fuel, and repaid Muawin from their Uber earnings.
What changed in the architecture
Two data sources instead of one
The API pulled from both Uber and Shell to build a credit profile, rather than relying on a single partner's data.
Disbursement to a supplier, not the borrower
Muawin routed the disbursement to Shell to credit the driver's fuel card. The money never touched the borrower's hands.
Repayment from earnings
Collections were deducted from the driver's Uber earnings, creating a closed loop that reduced default risk.
The core approval engine and needs-review portal worked without modification; a credit decision is a credit decision regardless of whether the output is cash or fuel. But the API layer needed to support multiple data sources feeding into a single decision, and the disbursement layer needed to route to a third party rather than back to the applicant. These extensions were designed as modular additions, not rewrites.
The Uber integration also delivered a 50% reduction in driver sign-up time because the credit application was embedded directly into the driver onboarding flow.
07 · Impact & Outcomes
The numbers after four months.
- 30k+Monthly transactionsAcross partner integrations
- 40%Of company revenueWithin 4 months of launch
- Same-dayApproval turnaround1 day → same-day if before 4pm
- +36%Monthly transaction volumeAfter shipping automated approval
- −50%Driver sign-up time (Uber)Embedded credit in driver onboarding
- 5 citiesPartner rolloutLive in 2 months from first integration
- 20k+New users via partners50% increase in user acquisition
- 3× YoYCompany revenue growthDriven across all product verticals
Beyond the metrics
A new business line, not just a feature
This product turned Muawin from a lender into a credit infrastructure company. The shift from "we lend to store owners" to "any company can lend through us" was a fundamental change in positioning and growth trajectory.
Fortune 500 validation
Integrations with Uber and Shell proved the infrastructure could serve enterprise partners, not just local apps. This changed the company's fundraising narrative and partnership pipeline.
A compounding flywheel
As more applications were processed, the approval model improved. Auto-approval rates climbed, the review queue shrank proportionally, and 20,000+ new users entered the ecosystem through partner channels without Muawin acquiring them directly.
08 · Reflections
What went well, and what I'd do differently.
What went well
Designing the system, not just the screens
The most impactful design decisions on this project had nothing to do with UI: the API field architecture, the automation thresholds, the queue workflow. Treating system design as product design was the right frame from the start.
The mandatory/optional field model
This decision unlocked partner adoption. A rigid API would have been more accurate from day one, but fewer partners would have integrated. The tiered approach traded early accuracy for adoption speed, then improved over time. It was the right tradeoff.
Building for flexibility
The Uber + Shell integration validated that the architecture could support product forms we had not anticipated. Designing modular input and output layers, rather than hardcoding for the grocery use case, paid off quickly.
What I'd do differently
Invest more in developer experience earlier
Partner engineering teams were the real "users" of the API. Better documentation, sandbox environments, and clearer error messages would have reduced the hands-on support needed during each new integration.
Instrument the review portal from day one
We knew the queue was the bottleneck, but lacked granular data on where reviewers spent time within each case. Better portal analytics would have let us iterate on the UX more precisely.
Formalize the automation threshold process
Adjusting the auto-approve/needs-review threshold was a judgment call informed by default rates and queue volume. A structured framework with clear triggers and decision criteria would have made the process less dependent on intuition.