PAYAZA GIVE

The Trust Layer Underneath the Contribution Platform.

This Case Study Covers The Trust Layer. It Has Two Surfaces.

One Is The Recipient’s Experience Of Getting Verified And Waiting For Their Funds. The Other Is The Back-Office Team’s Experience Of Doing The Verifying. Both Had To Be Designed Together. A System That Works For One Side And Fails The Other Isn’t A System At All.

Intro

The harder half of a contribution product isn’t the moment a donor clicks pay. It’s everything that has to be true for that click to become money in the recipient’s hands.

The harder half of a contribution product isn’t the moment a donor clicks pay. It’s everything that has to be true for that payment to clear, for the recipient to receive it, and for both parties to trust that the system underneath is doing what it claims to be doing. Held funds. Verification. Settlement cycles. Multi-currency reconciliation. Two-actor approvals. Audit trails. Reasons a payout was rejected, written in language a non-finance person can act on.

None of this is visible when the product is working. All of it becomes the product when something goes wrong.

This case study covers the trust layer. It has two surfaces. One is the recipient’s experience of getting verified and waiting for their funds. The other is the back-office team’s experience of doing the verifying. Both had to be designed together. A system that works for one side and fails the other isn’t a system at all.

The Trust Contract

A contribution platform makes three promises at the same time, to three different audiences, in the same moment.

To the donor: the money I’m sending will reach the person I’m sending it to.

To the recipient: the money you’re collecting is yours, and you’ll see it.

To the regulator: every cent that moves through this system can be traced, attributed, and justified.

These three promises do not naturally cohere. Donors want speed. Recipients want immediacy. Regulators want delay. The product has to honour all three without letting any of them feel the cost of the others.

The trust contract is where these promises meet. It’s the set of rules and behaviours that lets the system tell the donor “yes, your payment cleared” at the same moment it tells the regulator “and here’s the audit trail” at the same moment it tells the recipient “and here’s where your money is in the pipeline.” When the contract holds, all three audiences experience the system as trustworthy. When it breaks anywhere, it breaks everywhere.

Payaza Give carries an additional complication. It serves two user shapes through one product. Organisations (churches, NGOs, registered businesses, schools) go through KYB. Individuals (creators, influencers, freelancers) go through KYC. The compliance regime, the document set, and the risk profile differ between the two. But the product surface, the back-office team, and the regulator they answer to are the same. One system, two compliance shapes, three promises, three audiences. The trust contract has to absorb all of it.

The Two Surfaces

The trust layer expresses itself across two surfaces. They are not parallel; they are interlocking. A decision on one side rewrites the requirements on the other.

The recipient surface

This is where verification happens and where held funds wait. The recipient signs up, submits documents, watches the system review them, sometimes responds to a request for more information, and eventually sees their funds released. The surface has to be honest about what’s happening, specific about what the recipient can do next, and patient with the fact that the recipient is not a financial operator.

The admin surface

This is where the back-office team operates. Compliance officers review submissions and approve or request more information. Finance officers prepare payout batches. Finance managers confirm disbursements. Super admins configure the system. Every action they take is recorded. The surface has to encode the variance between account types, jurisdictions, and currencies, so the operator doesn’t have to carry it in their head.

Research

The research ran on three tracks, each with a different method and a different question.

1. Regulatory mapping across jurisdictions

(Method: document and verification matrix across UK, US, Canada, Nigeria, Kenya, South Africa)

We mapped the regulatory requirements for receiving contributions in each market Payaza Give operates in, producing a matrix of documents and verifications across six jurisdictions and two account types. The matrix wasn’t the deliverable. The deliverable was the shape of the variance, which clustered into four categories. Entity verification, individual verification, source-of-funds attestation, and jurisdictional flags (SCUML in Nigeria, FinCEN in the US, AML registration in the UK). The implication was that the recipient surface should expose category-level structure, not jurisdiction-level fields. The user sees “Business documents,” “Trustee documents,” “Banking details.” The system decides which specific documents map to each category based on country and account type.

2. Held-funds comprehension testing

(Method: comprehension interviews with 11 recipients, mixed organisation and individual)

We tested how recipients understood the held-funds state in early prototypes. The protocol was simple. Show them their dashboard. Ask them to describe, in their own words, what state their money was in, why, and what they had to do next. The early prototype failed the test. Recipients used words like “stuck,” “frozen,” “blocked,” and “not sure if I’ll ever see it.” The label “On Hold” was carrying connotations from other financial products (frozen accounts, fraud holds) that didn’t apply here. We rewrote the language. The fund state became “Awaiting setup completion.” The dashboard surfaced a persistent banner with the specific remaining steps. The held amount was framed in the positive (“You’ve collected $4000. Complete setup to release it”) rather than the negative. A second round of testing produced the right read. Recipients described the state as “almost done” or “waiting on my side,” not as a system block. The implication was that the held-funds pattern is a language problem before it is a design problem. The states the system tracks internally (On Hold, Aggregating, Awaiting Settlement) cannot be the states the user sees by the same names.

3. Back-office task analysis

(Method: contextual inquiry with 6 compliance and finance operators across two fintechs, plus shadowing of the existing Payaza ops team)

We studied how compliance and finance teams actually work. The pattern that emerged was that the highest-throughput operators didn’t review submissions one at a time. They reviewed in batches by document type, scanning all IDs, then all proof-of-address documents, then all bank confirmations. The conventional one-submission-at-a-time interface forced context-switching between document types and slowed the operator down. The implication was that the back-office should support both modes. A submission-centric view for individual review, and a document-type-centric view for batch review. The operator picks the mode based on the queue shape. The same study surfaced the Maker-Checker pattern as standard practice for payout approvals. One operator generates the payout instruction; a second operator confirms the disbursement. The control isn’t bureaucratic. It’s the lowest-cost mechanism for catching errors that would otherwise reach a customer’s bank account.

The Build

Six decisions. Three on the recipient surface, three on the admin surface. Each decision rewrites a requirement on the opposite side.

01 / 07

04Compliance dashboard (unified admin queue)

05Admin review screen (single submission)

Decision 1:

Route account type by behaviour, not by interrogation

Users often don’t know whether they’re a business or an individual when they sign up. Asking up front produces wrong answers and a feeling of being tested.

The decision was to route by behaviour. The user names what they’re collecting for. The system surfaces the right path. Switching is free.

The Design A single routing step with one question: “Who is collecting?” Two options. Organisation. Individual. The choice drives the document set, the language, and the time estimate on the next screen. Default is “individual,” because the cost of being wrongly routed to KYB is higher than the cost of being wrongly routed to KYC.

Decision 2:

Hold funds as a project, not a status

Recipients collect contributions before verification completes. Those funds sit in a held state. The pattern works if the recipient understands the path forward. It fails if it reads as a block.

The decision was to treat the held state as a project. A project has next steps, visible progress, and an end. A status has none of those.

The Design A persistent setup card at the top of the dashboard. It shows the amount held, the remaining steps in plain language, and one CTA pointing to the next pending step. Inside the held-funds list, each batch carries a tooltip explaining why it’s held and what unblocks it. System status labels (On Hold, Aggregating) map to user-facing language (Awaiting setup, Processing) at the surface. The underlying state machine stays operational for the admin side.

When verification completes, held batches move to “Processing” automatically. The setup card collapses. The recipient gets a notification confirming the release.

Decision 3:

RFI as conversation, not rejection

The compliance team often needs more information mid-review. The conventional pattern is a “rejected” state. Recipients read that as failure.

The decision was to design Request for Information as a continuation of verification, not a break from it.

The Design When an RFI is raised, the recipient gets an email and an in-product banner. The banner names the specific document and links directly to the upload screen for it. The original submission stays visible alongside the new one. The language is conversational: “We need a clearer copy of your business document,” not “Your document was rejected.” Recipients keep collecting contributions during RFI.

Decision 4:

One queue, type-aware

The compliance team reviews both organisations and individuals through one back-office. The surface had to flex by account type without forcing context-switching between two mental models.

The decision was to make account type a property of the submission, not a separate product. One queue. One review screen. Filters and document sets that flex by type.

The Design A unified queue with account type chips on each row. Clicking a submission opens a review screen with exactly the documents that apply to its type and jurisdiction. The operator never sees an irrelevant field. Two review modes: submission-centric for one-at-a-time work, document-type-centric for high-throughput batches. The operator picks based on queue shape.

Decision 5:

Maker-Checker as a first-class workflow

Payouts move across multiple currencies and rails. Errors hit a recipient’s bank account and are expensive to recover from.

The decision was to design Maker-Checker as a workflow, not a process layered on top. The product encodes the separation.

The Design Three columns: Awaiting Maker, Awaiting Checker, Completed. Each row carries batch metadata (merchant, account type, currency, total amount, rail). The Maker prepares the batch. The Checker confirms disbursement with a confirmation phrase. Neither can complete the other’s step. Every action is logged with admin email, timestamp, and IP. Downstream failures roll back to the merchant’s withdrawal balance.

Decision 6:

Audit trail as a live surface

Audit trails are usually logs surfaced only when a regulator asks. That makes them useful for compliance and useless for daily operations.

The decision was to design the audit trail as a surface the team uses every day, not a record they produce on request.

The Design The Activity Center is a top-level admin surface. Every action (a business approved, a payout rejected, an admin invited) appears as a feed entry with admin email, timestamp, action type, and affected merchant. The feed is searchable. The regulator-facing export is a downstream artefact of the same data. Logs are tamper-proof: once written, they cannot be edited or deleted, only superseded.