A regulations compliant multi-tenant loan collection platform for Saudi Fintech

FinTechMulti-Tenant SaaSCompliance

Client

Munjz

RoleLead Product Designer,
Product Architecture & Compliance UX

Platforms

Desktop

Tools Used

Figma

ChatGPT

Excel

TL;DR

0→1 multi-tenant collections platform for Saudi financial institutions, governed by SAMA/CMA.
Lead Product Designer owning UX strategy, information architecture, and compliance-by-design.
Designed guardrails (contact caps, audit trails, consent flows) and role-based workspaces for admins, agencies, and agents.
Built native Arabic/English (RTL/LTR) support from day one to scale across institutions.
Outcome: Launched MVP under a 12‑week timeline, reduced non-compliant behavior risk, and created a reusable governance model for future fintech products.

About the Project

Munjz is a tenant-based loan collections platform built for the Saudi financial ecosystem. It connects banks, agencies, agents, and customers into a single governed SaaS environment, where every interaction must comply with SAMA and CMA regulations.

Before Munjz, collections were fragmented across spreadsheets, phone calls, and agency-specific tools, making compliance hard to audit and even harder to enforce consistently.

Problem Statement

Debt recovery platforms in the region were fragmented, institution-bound, and heavily dependent on agent judgment for compliance.

Most systems:

Were built per institution, not for shared governance
Relied on training and policy documents to enforce regulation
Encouraged aggressive recovery patterns that increased customer stress
Lacked structural auditability and tenant isolation

This wasn't a UX gap.
It was a system design gap in a regulated, multi-tenant environment, where failure meant legal and reputational risk.

Key Users, Their Needs & Pain Points

Constraints

Every design choice had to live inside these constraints; there was no option to 'design around' them.

Strict SAMA & CMA regulatory requirements

Every contact, status change, and payment action had to be traceable and defensible in front of a regulator.

Mandatory audit trails for sensitive actions

Actions like changing debtor status, modifying payment plans, or closing a case needed clear "who/what/when/why" records.

Multi-tenant data isolation

Banks and agencies share the same platform but must never see each other's data.

Bi-directional localization (Arabic / English)

Interfaces had to feel native in both languages, structural RTL/LTR mirroring, not just translated copy.

Fixed MVP delivery timeline

We had a fixed time line of 23 weeks to ship something real, and robust, within that timeline the design window is even more shorter.

Solution, Architecture Is the UX

The solution was not to "design around" regulation, but to turn regulation into the system's operating logic.

Munjz was designed as a decision architecture where:

Non-compliant actions are structurally prevented
Risky behaviors are slowed down through intentional friction
Each role sees only what it is permitted to act on

UX was not layered on top of rules, it was the control surface.

Role-Based Information Architecture

The platform's information architecture defines access boundaries, compliance guardrails, and permissible actions per role.

Modular role hierarchy

Super Admin, Agency Admin, Agent, Customer, and future roles (Compliance Officer, CFO, etc.) fit into a consistent permission matrix. New roles can be added by extending the model, not reworking it.

Tenant-agnostic flows

Workflows for case assignment, payment negotiation, and escalation are decoupled from institution-specific rules, allowing tenants to configure policies without UI redesign.

Pluggable governance layers

As regulations evolved or new institutions had unique requirements, the IA could layer new constraints (e.g., enhanced audit for high-risk portfolios) without breaking existing user workflows.

Data boundaries as first-class citizens

Data isolation was baked into the IA from day one, not bolted on later. This meant scaling to 50 institutions was as safe as launching with 1.

Explore the complete role hierarchy, permissions, and data isolation model in Figma.

Key Decisions I Owned

Compliance as a Hard Constraint

Embedded regulatory rules directly into UI interactions. Contact limits enforced structurally, not by training.

Contact limits enforced structurally, not by training

Designed role-based, tenant-safe views

Each role sees only what they need to act on, with strict data isolation between tenants.

Each role sees only what they need to act on

Built RTL/LTR parity as a first-class system constraint

Native Arabic/English from MVP, not an afterthought. Structural RTL/LTR mirroring, not just translated copy.

Native Arabic/English from MVP, not an afterthought

Trade-Offs

AI-driven prediction

Ideal: AI-driven predictive segmentation and automated case routing.

What we did in the MVP: Used transparent rule-based logic that admins can configure per tenant.

Why: We didn't yet have the historical data or risk appetite for a "black box" model; rules gave immediate value and were easy to explain to regulators and stakeholders.

Verification

Ideal: Real-time document verification via government and third‑party APIs.

What we did in the MVP: Built a manual verification queue where Super Admins review and approve uploaded documents.

Why: API integrations were high-risk within the 23‑week timeline; a manual flow let us launch safely while keeping a clear path to future automation.

Negotiation

Ideal: Fully self‑serve customer negotiation with automated approvals and counter‑offers.

What we did in the MVP: Kept payment plan creation and changes agent‑led, with customers reviewing and agreeing via the portal.

Why: Financial risk needed to stay with humans during rollout; this preserved control while still improving transparency for customers.

High-risk actions

Ideal: Seamless, frictionless workflows for all actions to maximize efficiency and speed.

What we did in the MVP: Introduced confirmation and reasoning requirements for high-risk escalation actions, adding intentional friction.

Why: Intentional friction prevents accidental violations while creating immutable audit trails. This structural approach ensures compliance is built into the workflow, not dependent on training.

Each trade-off favored risk reduction and trust over speed.

Wireframes

Before committing to UI, the focus was on proving the governance model and workflows in low fidelity. These wireframes were used with product, engineering, and compliance stakeholders to validate that the system could support real incidents, not just ideal flows.