Context
What was actually broken
When a merchant completed the sign-up flow, their application didn't land in a clean queue. It landed in a spreadsheet. Four different teams — Business Development, Compliance, Credit, and Operations — would pull from the same file, make notes in separate columns, send status updates over WhatsApp, and try to coordinate approvals across a process that had no single source of truth.
The sign-up flow was designed to feel simple for the merchant. The approval process, by contrast, was entirely undesigned. Everyone had a workaround. Nobody had visibility into what the other teams had already checked. Applications stalled at handoffs. Merchants got approved or rejected without a clear audit trail of why.
The design brief wasn't "build an admin panel." It was replace a four-team coordination system that was running entirely on spreadsheets and messaging apps.
The goal was a single internal portal where each team could do their specific part of the review — see only what they needed, take only the actions they were authorized to take — while the system tracked the full picture automatically.
Structure
Four teams, one merchant file
Before designing anything, the work was mapping exactly what each team did, in what order, and what decisions they needed to make. Every team had a different relationship to the merchant's data.
Business Development
First contact. BD sees the full application, assigns ownership, tracks communication history, and decides whether the merchant clears the initial threshold before any compliance or credit work begins. If BD passes the application, it moves forward. If not, it stops here.
Compliance
Document verification. Compliance enters through the same shared queue as the Credit team, then opens each merchant file to review the required documents against Saudi regulatory requirements. Each document gets an individual status. The merchant cannot proceed without full compliance sign-off.
Credit
Financial assessment. Credit shares the same queue view as Compliance but opens a different set of panels inside each merchant file — WATHQ verification, IBAN check, open banking consent, and bank statement review — culminating in a credit limit decision tied to specific signatories.
Operations
Final activation. Once all three prior teams have signed off, Operations generates the contract, dispatches it for e-signature, and activates the merchant account when everything is confirmed.
Business Development
The queue that didn't exist
The BD team's version of the spreadsheet workflow was the most chaotic. Applications came in with no structure. Ownership was informal — whoever noticed it first would pick it up. There was no way to know if a colleague had already started reviewing something, no way to track where a conversation with a merchant had gone, and no record of why an application had been held or rejected.
The BD view in the portal was designed around two things: assignment and status. Every application is clearly owned. Every application has a visible stage in the overall pipeline. The BD team member can see their own queue, see unassigned applications, and access the full merchant profile. The initial pass/fail decision made by BD is documented. If BD rejects an application, the reason is recorded and the merchant is notified. If BD approves, the application advances automatically to the compliance queue.
Compliance
Seven documents, one decision
Compliance review in the old system meant downloading attachments from a spreadsheet, opening them individually, checking each one against a mental checklist, and making a note in a cell. There was no standard for what "reviewed" meant, no record of who checked what, and no way to see if a document had been updated since the last review.
Compliance and Credit both enter through the same shared queue table. Where they diverge is inside the merchant file: a compliance officer opens the documents tab, a credit officer opens the verification and banking tabs. The table is the same; the work they do from it is entirely separate.
The compliance view within a merchant file is a document-by-document checklist with individual statuses. Each required document gets its own row: the file, the current status (pending, approved, rejected), and a notes field. The sign-off button only becomes active when every document has a final status — making the definition of "compliance review complete" unambiguous.
Credit
Risk assessment with live data
The Credit team's job is the most data-intensive step in the process. They're making a financial judgment about what the merchant can be trusted to borrow. That requires pulling data from two external government APIs, reviewing bank statements, and issuing a credit decision that has direct revenue implications.
Merchant Profile
When a credit officer opens a merchant application, they see the complete profile: general business information, document attachments, and the representative information pulled from the commercial registration. The portal surfaces two views of the representative data — one for LLC structures, one for sole proprietorships — because the required fields and signatory logic differ between them.
AML Check
Before any financial assessment begins, the system runs a terrorism financing and money laundering check against the merchant and their representatives. The result surfaces directly in the merchant file. A failed check blocks the credit decision from being submitted — there's no workaround, and no way to proceed without the flag being reviewed and cleared by the appropriate team.
WATHQ — Live Company Verification
WATHQ is the Saudi government's commercial registry. The portal automatically pulls company data from WATHQ when a credit officer opens a merchant file — registered name, CR number, ownership structure, management and board, capital breakdown. The officer doesn't run a separate lookup; the data surfaces inline across five tabs, matched against what the merchant submitted. If there's a discrepancy, it's visible immediately.
WATHQ — live company data, five panels
Company info & business activities — registered name, CR number, legal structure, activity codes
Ownership structure — shareholders, ownership percentages, and individual ID verification
Management & board — appointed managers, authorized signatories, board membership
Capital — registered capital amount and contribution breakdown
Stock capital — share structure and allocation across owners
Bank Review — Requesting Open Banking Consent
Bank statement review works as a two-sided flow. The credit officer initiates it by generating an open banking consent link directly from the portal and sending it to the merchant. The merchant then completes their side — connecting their bank account via IBAN — and the portal returns the bank data automatically. The credit officer never needs to handle raw PDFs or manually log what they found.
Before the merchant consents, the credit officer sees a set of clear states: no link sent yet, link generated and pending, link expired, merchant opted out, or skipped. Each state has a specific next action available.
Bank Review — Before Consent (Credit Team view)
Default — no consent request sent yet. Credit officer can generate a link or skip this step.
Generated — link sent to merchant. Portal shows sent status and timestamp while waiting for consent.
Expired — link timed out. Officer can regenerate and resend without losing any other review progress.
Opted out — merchant declined open banking. This is a logged state; the team manually reviews uploaded bank statements instead.
Skipped — officer proceeds without open banking. A flag is attached to the merchant file for audit purposes.
Merchant View
What the merchant sees: IBAN & open banking
When the credit officer generates the consent link, the merchant receives it on their portal. They go through a structured IBAN verification and open banking consent flow — entering their IBAN, confirming their bank, and authorizing the data connection. The merchant never speaks to the credit team directly; the portal handles the entire exchange.
If the IBAN doesn't match or needs to be corrected, there's a dedicated adjustment flow — not an error state with nowhere to go, but a clear path to resubmit with the correct information.
IBAN & Open Banking — Merchant view
Step 1 — Merchant enters IBAN. The field validates format in real time before submission.
IBAN submitted — system verifies against BAYAN and returns bank name and account holder for merchant to confirm.
IBAN confirmed — merchant proceeds to open banking consent step.
Open banking consent — merchant reviews data scope and authorizes the connection to their bank.
Consent given — bank data connection authorized. Merchant is done; credit team is notified automatically.
Complete — merchant sees confirmation. No bank credentials were shared; the connection uses open banking protocols.
IBAN Adjustment
When the IBAN needs to change
If the merchant's IBAN doesn't match the legal entity on file, or if the credit team requests a correction, the merchant goes through a dedicated adjustment flow rather than starting from scratch. The adjustment preserves everything already reviewed — only the IBAN is updated, reverified, and resubmitted for the credit team to confirm.
IBAN Adjustment flow — Merchant view
Adjustment initiated — merchant enters the corrected IBAN. Previous IBAN shown for reference.
New IBAN verified via BAYAN — bank name and account holder returned for merchant confirmation.
Adjustment confirmed — new IBAN replaces the previous one in the merchant file.
Complete — credit team is notified of the update and can re-review the banking data.
Credit — Bank Data Review
After consent: reviewing what came back
Once the merchant completes the open banking flow, the portal notifies the credit officer and populates the bank review section with the returned data. The officer reviews the bank statements directly in the portal, can request adjustments to the data scope if needed, and submits a final bank review decision that feeds into the credit limit assessment.
The adjustment capability is a key detail: if the statements show a date range or account scope that needs to change, the officer can request a specific adjustment, log the reason, and track the adjustment through to completion — all without leaving the merchant file.
Bank Review — After Consent (Credit Team view)
Consent received — portal fetches bank data and notifies the credit officer the file is ready for review.
Bank statements — account activity surfaced inline. Officer reviews transactions, balance trends, and revenue patterns.
Adjustment requested — officer specifies what needs to change in the bank data scope.
Reason logged — adjustment reason is required and becomes part of the merchant's permanent audit trail.
Sent — merchant notified. Portal shows pending status while the adjustment is in progress.
Pending decision — bank review complete, waiting for credit officer to submit the final assessment.
Finished — bank review decision submitted. Application advances automatically to the credit limit step.
Operations & Contract
Financing limit, contract, activation
Once the credit decision is submitted, the merchant is notified of their approved financing limit on their portal. The limit is the output of the credit team's full assessment — WATHQ data, BAYAN IBAN verification, and bank statement review all feed into the number the merchant sees. It's not shown as a provisional figure; it's the confirmed limit that will appear in their contract.
Financing Limit — Merchant view
Limit revealed — merchant sees their approved financing amount for the first time.
Limit details — breakdown of what the limit covers and how it can be used.
Merchant acknowledges the limit before proceeding to contract review.
Confirmed — merchant proceeds to the contract, generated with the approved limit pre-filled.
Contract — Merchant view
Contract displayed — auto-filled with legal entity name, IBAN, credit limit, and signatory details from the merchant file.
E-signature — merchant signs the contract digitally. No printing, no scanning, no back-and-forth over email.
Signed — contract confirmed. Operations activates the account. The merchant is ready to use Madfu Business.
Design Challenges
What made this hard to design
Designing a two-sided flow without a seam
The open banking step is the most visible example of the two-surface structure: the credit officer sends a request, the merchant completes their side, and the portal updates the credit team's view automatically. From both sides, the experience feels like a single linear process. Underneath, it's a handoff between two completely separate surfaces that have to stay in sync without either party waiting, polling, or chasing the other through a messaging app.
Permissions without confusion
Each team can only take actions appropriate to their stage. BD can assign and pass or reject. Compliance can approve or reject documents. Credit can run verifications and submit a decision. Operations can generate contracts and activate accounts. But the merchant's file — the same underlying data — has to be visible to all of them in a way that feels complete, not redacted. The solution was a single merchant record with role-scoped action panels. The data is shared; the actions aren't.
Making the audit trail effortless
Compliance requirements meant that every decision had to be logged with a timestamp and the identity of the person who made it. In the portal, the audit trail is automatic. Every status change, every document approval, every adjustment reason, every credit decision is logged without the team member needing to do anything beyond the action itself. The logging is invisible — it happens in the background. What the team member sees is a clean interface for doing their job.
The hardest design challenge wasn't any one screen. It was making sure that every team always knew exactly where the application stood, without needing to ask anyone.
System Resilience
Designing for the moments it breaks
An internal tool handling financial approvals and regulatory documents cannot treat error states as edge cases. API calls fail. Consent links expire. Identity checks return mismatches. The portal had to handle all of these without leaving a team member stranded mid-review — and without blocking the entire workflow when only one part of it has a problem.
API failure — open banking consent
If the open banking API fails when the credit officer tries to generate a consent link, the portal shows a specific error state with a retry action — not a generic message, not a blank panel. The failure is logged. The officer can retry immediately or continue with the manual bank statement review path. A failed API call doesn't block the credit review; it creates a logged flag requiring manual confirmation before the credit decision can be submitted.
Bank data errors after consent
After the merchant consents, the bank data return can fail for several reasons — a connection timeout, an unsupported account type, or a data format issue from the bank. These aren't presented as dead ends. The portal shows the specific error with a clear explanation and the available recovery actions: retry the data pull, request a different account, or fall back to manual statement review. The credit review is not blocked. Only the automated data pull is in a failed state, and there's always a manual path forward.
Identity verification failures
The AZM identity verification check can fail for the merchant's authorized representatives — this is distinct from the AML check and can happen due to mismatches between the submitted ID and the commercial registration data. The portal shows separate failure states for LLC structures (where multiple representatives may need to be verified) and sole proprietorships (single owner). In both cases, the failure is specific: which representative failed, why, and what the credit officer needs to do next.
Error states were treated as first-class design problems. Every broken state has a recovery path. No broken state leaves the team member without a next action.
Reflection
What this project was really about
Internal tools don't get praised for being beautiful. They get evaluated by whether the people who use them every day feel like the tool is helping or getting in the way. The benchmark for the approval portal was never aesthetics — it was whether a credit officer could open a merchant file, run a WATHQ check, send a consent link, review the returned bank statements, and submit a credit decision without switching tabs, sending a message, or losing track of what was still outstanding.
The merchant doesn't see this portal. They see a clean sign-up flow and a notification when they're approved. The approval portal is the invisible infrastructure that makes that experience possible.
Four teams with separate workflows, separate data needs, and separate authority levels now work from a single system. The open banking handoff that used to require a phone call and a PDF attachment is a two-sided flow that completes itself. The audit trail writes itself. The handoffs happen without WhatsApp messages. The complexity didn't go away — it got absorbed by the design, so the people using the system don't have to manage it manually.