Designing a Back Office System for Compliance, Operations, and Risk Control

The early modal-based review flow was useful for a smaller team, but it was not built for the level of context payment review eventually required.

Reviewers were not only checking whether a payment had been submitted correctly. They needed to compare invoices against payment details, confirm whether the beneficiary information was reliable, understand what the sender was allowed to make payments for, and act on issues or rejection history attached to the payment.

The interface started to create friction because the information reviewers needed was split across different surfaces.

Key limitations included:

• Review was limited to a modal-based interface
• Invoice and payment details could not be viewed together
• Payment context was fragmented and easily lost
• Reviewers had to download invoices or switch between views to compare information
• Increasing operational complexity made the approach difficult to scale

The review process had become more investigative, but the interface still treated it like a basic approval action.

To support this shift, I moved the system from a modal-based flow to a side-panel review model.

The goal was to keep the payment details accessible while creating more room for the supporting context reviewers needed to make a decision. This included actions, remarks, notes, attachments, review stage, beneficiary details, and other contextual information that could not comfortably fit inside a simple modal.

The side-panel model gave the review flow more flexibility. It allowed reviewers to stay inside the payment list while opening a richer review surface beside it. This meant they could inspect a transaction without losing their place in the broader payment queue.

The tradeoff was that the interface became denser, but that was intentional. For internal compliance and operations users, the priority was not minimal UI. It was having the right information available at the moment a decision was being made.

One of the most important workflow insights came from how reviewers actually worked.

The invoice was often the first thing they opened. Reviewers would use it as a source of truth, then compare it against the payment details, beneficiary information, amount, invoice number, and purpose of payment.

In the old flow, this comparison was awkward. Opening or downloading the invoice took the reviewer away from the payment details, forcing them to switch between windows or manually compare information across separate views.

To solve this, I introduced a side-by-side invoice viewer. This allowed the invoice and payment details to remain visible at the same time, turning comparison into a native part of the review experience.

This introduced more information on screen, but we prioritized accuracy over visual simplicity. In a financial system, reducing review errors was more important than keeping the interface visually minimal.

As payment volume increased, the review burden became less about whether information was available and more about whether reviewers could trust the information in front of them.

A payment could have all the required fields filled out and still require deeper judgment. Reviewers needed to know whether the sender's business context aligned with the payment, whether the beneficiary information was reliable, and whether the attached invoice looked consistent with previous invoices from the same beneficiary.

To reduce repeated manual checks, I introduced trust signals directly into the review flow:

• Business remarks helped reviewers understand what a sender was approved to make payments for
• Beneficiary confidence indicators showed how reliable specific beneficiary details appeared based on validation and past usage patterns
• Invoice history and archetyping helped reviewers compare submitted invoices against known examples from the same beneficiary

This made payment review less dependent on memory, manual investigation, or individual experience. It gave reviewers more context at the point of decision and helped them act with more confidence.

As payment review became more collaborative, the back office needed a way for compliance and operations teams to discuss specific transactions without moving the conversation into Slack, WhatsApp, or separate internal notes.

I introduced payment comments as an internal collaboration layer within the review flow. Reviewers could leave comments, tag teammates, and attach supporting files directly to a payment. This kept the conversation tied to the transaction itself, so anyone reviewing it later could understand what had been discussed, who had been involved, and what context influenced the decision.

This was especially useful for payments that required a second opinion, additional document review, or clarification from another internal team member. Instead of separating the discussion from the transaction, comments made collaboration part of the payment record.

As more people became involved in payment review, it became important to preserve a clear history of what happened to each transaction.

I designed the transaction timeline to give reviewers a chronological view of key actions taken on a payment. This included when a payment was created, updated, declined, approved, or otherwise acted on, along with who performed each action.

Each transaction included:

• a full timeline of important events
• action history
• user attribution
• supporting details for key events, such as declination messages or field changes

This helped make the review process more transparent and auditable. Reviewers no longer had to rely on memory or ask around to understand what had happened previously. The system preserved that context directly inside the payment review experience.

As payment review continued to grow in complexity, the side-panel model also started reaching its limits.

More context had to be attached to each payment: comments, AI checks, declination logs, errors and issues, rejection history, invoice history, and payment timelines. Keeping all of that stacked inside a single side panel made the experience harder to scan and reduced the space available for the actual payment details.

This led to the next evolution of the review experience: a full review workspace.

In this model:

• Payment details remained the stable source of truth
• Contextual tools were organized into a structured menu
• Supporting views such as invoices, logs, comments, AI checks, errors, and declinations were separated into dedicated panels

This gave the system more room to grow. Instead of forcing every review layer into the same narrow panel, the workspace separated primary payment information from supporting review tools.

It also created a more consistent structure for future complexity, allowing new review layers to be added without overwhelming the main payment details.

Beyond the visual redesign of the payment review experience, this was also where we began introducing AI as an assistive layer in the review process.

The goal was not to replace manual review. Compliance still required human judgment. Instead, AI was introduced to help surface signals faster, summarize potential concerns, and support reviewers while they continued their manual checks.

The AI check could run in the background while a reviewer continued inspecting the payment. Once complete, the result appeared as a structured review layer with a summary, risk signals, score, and verdict.

This created a new design challenge. AI added another layer of context to an already complex review system. If it was treated as just another sticky section inside the old layout, it would compete with payment details and make the interface feel heavier.

By moving to a full review workspace, AI could exist as a dedicated review layer without disrupting the core payment details. Reviewers could open it when needed, inspect the result, and return to the payment context without losing their place.

This helped position AI as a support system within the workflow, not a black box making decisions on behalf of the reviewer.

The redesigned payment review system reduced context switching, improved review speed, and made it easier for teams to process higher transaction volumes without increasing operational overhead.

More importantly, it transformed payment review from a simple approval flow into a structured decision-making system.

Reviewers could now compare invoices and payment details side by side, access trust signals directly inside the workflow, review history and contextual issues, and use AI-assisted checks without leaving the payment review experience.

This gave Plumter a payment review system that could scale with the complexity of the business.

The early KYC review flow was not built for the depth of verification the team eventually needed.

A single submission could include multiple business documents, several directors and shareholders, identity checks, ownership details, business profile information, and historical updates. Each of these items could require its own review, decision, or follow-up.

The main limitations were:

• Heavy reliance on document inspection
• Need for identity verification and validation
• Difficulty tracking relationships between individuals and businesses
• Fragmented compliance knowledge across the team
• Too many checks happening outside the review interface

KYC review was not just about validating submitted information. It required understanding relationships between entities, verifying identities across multiple sources, and identifying risk signals early.

To support this complexity, the KYC review experience evolved from a simple modal into a layered review workspace.

The goal was to give reviewers enough structure to move through a submission systematically, without losing access to important context. Business details, documents, ownership information, checklist items, conflicts, and verification actions all needed to live close to the review surface.

The system evolved to support:

• Document-heavy workflows
• Real-time verification
• Multi-step review processes
• Contextual actions on specific KYC items

This shift made the review process more scalable. Instead of treating KYC as one large approval decision, the interface allowed reviewers to inspect and act on individual parts of the submission while still understanding the submission as a whole.

As the compliance team grew, one of the biggest challenges was consistency.

A lot of KYC review knowledge lived outside the product. New reviewers depended on internal notes, shared documents, or verbal guidance to understand what needed to be checked before a business could be approved.

To reduce that dependency, I introduced an in-product compliance checklist.

The checklist gave reviewers a structured way to move through required checks and track progress as they reviewed a submission. It also gave the team a way to standardize review expectations across different reviewers.

This helped turn compliance knowledge from something passed around informally into something embedded directly inside the workflow.

For reviewers with permission, the checklist could also be updated, which allowed the team to adapt the review process as internal requirements changed.

One of the most important KYC challenges was identifying when the same individual or information appeared across multiple businesses.

I introduced a conflict detection system that surfaced potential matches during review. If a director, shareholder, email, ID number, or other key detail appeared to overlap with another business, the system flagged it for further investigation.

This allowed reviewers to:

• Identify relationships between businesses and individuals
• Investigate potential risk signals
• Compare conflicting data in context
• Access historical information before making a decision

This shifted KYC review from basic document checking into relationship-aware investigation. Reviewers could see not only what was submitted, but also how that submission connected to existing entities in the system.

Some KYC checks originally required reviewers to leave the review flow or use a separate page.

This was disruptive because identity and document verification needed to happen while the reviewer still had the submitted information in context.

I redesigned these checks to happen inline within the review experience.

Verification actions such as ID checks could be triggered directly beside the relevant information, allowing reviewers to run checks, inspect results, and continue reviewing without losing their place.

This reduced disruption during review, even though it required careful structuring to avoid overwhelming the interface.

The goal was to make verification feel like part of the review process, not a separate task.

KYC submissions often had multiple issues across different sections.

A business might submit the wrong document, provide unclear ownership details, upload an outdated file, or have a specific director that required further clarification. Handling these issues one by one created unnecessary back-and-forth with users.

Declination logging allowed reviewers to collect multiple issues during review and send them as one structured response.

Instead of immediately rejecting each item in isolation like we previously did, reviewers could log issues as they found them, review the full set, and then send a clearer response to the user.

This made feedback more complete, reduced repeated correction cycles, and helped users understand exactly what needed to be fixed before approval.

As the KYC system continued to grow, the layered side-panel model eventually needed more structure.

The review flow now included compliance checklist, AI check, declination log, errors and issues, vendor notes, invoices, payments, business profile information, ownership structure, documents, and inline verification actions.

To support this, the KYC review experience evolved into a full-page review workspace with a collapsible toolbar.

In this version:

• Core KYC details remained the main source of truth
• Review layers like AI check, checklist, declination log, errors, and vendor notes were organized into a structured menu
• Checklist and review tools could open beside the KYC details instead of crowding the main content

This brought KYC closer to the same scalable review model used in payment review, creating consistency across the back-office system.

The redesigned KYC system improved consistency across reviewers, reduced onboarding time for new compliance team members, and allowed more complex verification workflows to be handled without increasing operational friction.

More importantly, it transformed KYC review from a simple approval flow into a structured investigation system.

Reviewers could inspect documents, verify identities, detect conflicts, follow a checklist, log multiple issues, and access supporting context without leaving the review experience.

This gave Plumter a KYC review system that could scale with the complexity of the businesses being onboarded.