Factoring System Design
Transforming a fragmented financial operation into a scalable enterprise platform through Systems Thinking
Enterprise Product Design · Systems Design · Information Architecture · UX Strategy · Design Systems
Duration: 3 months
Company: Bertoni Solutions (Denmark) - Advance Factoring (Perú)
Year: 2026
Role
Senior Product Designer · System Designer · UX Researcher
Domain
Financial Services · Enterprise SaaS · Factoring Operations
Core focus
Operational architecture, validation logic, information architecture, UX, design system
Primary users
Operations team; supporting stakeholders included Financial Direction, Commercial, Treasury and Administration
Key artifacts
Business flow map, information architecture, validation framework, debtor-type cards, BFF architecture, design system, QA coverage
Project Gallery
1. Executive summary
Advance Factoring is an enterprise platform designed to centralize the operational management of factoring transactions. The product brings together operation monitoring, documentation, validation, processing, status management, advances and follow-up in a single environment. The challenge was larger than designing a dashboard. Factoring operations depend on distributed information, multiple stakeholders, financial controls and conditional validation requirements. The product needed to make that complexity understandable and actionable without turning every business variation into a separate workflow. My contribution was to connect the business domain with product architecture. Through conversations with the Financial Director and an Operations user, I learned that the business already recognized six recurring approval profiles. Those profiles were part of operational knowledge, but they were not explicitly used as the organizing structure of the approval experience. The key design opportunity was not to invent new approval rules, but to make existing business knowledge explicit, reusable and actionable in the product. I translated this domain knowledge into a validation-oriented system while keeping an important distinction between three different concepts: user roles, approval profiles and debtor types. This separation became essential for creating a scalable product architecture.
2. Business concept
Factoring operations require coordination between commercial, operations, treasury and clients before a transaction can be completed. Information and decisions move through several stages, while documentation and validation requirements vary according to the financial context. The existing process depended on multiple reviews and dispersed information. The product documentation describes the target platform as a centralized environment for consultation, document validation, processing, status updates and operational follow-up. Dashboard and operational monitoring Operations list and search Operation detail Document validation Operational processing Advance requests Status updates End-to-end follow-up
3. The problem
The initial problem appeared to be fragmented information and manual follow-up. The deeper product challenge was that financial validation requirements were conditional, while the operational experience needed to remain simple and consistent. If every debtor scenario became its own workflow, the platform would accumulate duplicated screens, duplicated logic and more opportunities for inconsistency.
.png)
User interviews drove the core of users pain points detection and business constraints.
4. Research and Domain Discovery
The discovery was focused on the operational reality of the business. Conversations with the Financial Director and an Operations user revealed that the organization already had a mental model of six recurring approval profiles. The important finding was not the creation of those profiles. The business already recognized them. The design insight was that this knowledge was not being explicitly encoded into the approval system. This shifted the design task from designing an isolated Advance Factoring workflow to designing a reusable validation mechanism that could express the business rules without reproducing the entire workflow for every scenario.
The design opportunity was not to invent new approval rules. It was to turn existing financial knowledge into one reusable validation process.
User interviews drove the core of users pain points detection and business constraints.
5. The turning point
The six approval profiles became an important part of understanding the business domain, but they are not the same thing as the eight debtor types. The final system architecture must preserve that distinction.
Business knowledge
8 approval profiles already recognized by the business
Product design decision
Use as domain knowledge informing the approval logic
8 debtor types with different validation requirements
Review independently inside the same validation process
Different required checks by debtor type
Render a dynamic checklist within a consistent experience
This distinction is critical: I did not design eight separate approval workflows, nor eight separate validation workflows.
I designed one validation process capable of independently evaluating the eight debtor types.
6. The Core System Design Decision
The validation model.
One validation process handless eight debtor types. The requiered checks change by type while the experience remains consistent.
👁️ Clic to see complete image
.png)
The system follows a single validation journey. The operation identifies the debtor type, the same validation process evaluates the requirements applicable to that type, then when user send all requierements, they are validated and documented. The result is a clear operational state and decision.
7. Validation CORE
The functional specification describes a Validation CORE with eight cards, one per debtor type, and a dynamic checklist according to business rules.
LAYER
Validation process
Debtor type
Business rules
PURPOSE
Single reusable operational flow
Determines the scenario being evaluated
Determine which checks are required
Checklist
Makes required validation explicit
Validation state
Shows what is complete and what remains
Operational decision
Allows the user to progress or stop the operation
The Eight Debtor Types
Example of Debtor types. Each one shows different checklist requirements.
The eight debtor types have different minimum validation requirements. The product documentation specifies combinations of email verification, account annotation and Cavali confirmation depending on the type.
DEBTOR
Representative validation requirements
1
Email sent + email responded + account annotation + explicit Cavali confirmation
2
Email sent + email responded + account annotation + presumed Cavali confirmation
3
Email sent + email responded + account annotation
4
Account annotation + explicit Cavali confirmation
5
Account annotation + presumed Cavali confirmation
6
Client email sent + email responded + account annotation + explicit Cavali confirmation
7
Client email sent + email responded + account annotation + presumed Cavali confirmation
Client email sent + email responded + account annotation
8
9. Information Architecture
The information architecture organizes the operational experience around the user's work: operations list → operation detail → validation → processing → follow-up.
Information architecture.
10. End-to-End Operational Flow
The flow map shows how the platform connects Commercial, Operations, Treasury and Client activities. Use this artifact to demonstrate system-level thinking before showing interface details.
![[Advance Factoring] BFF.jpg](https://static.wixstatic.com/media/51869a_3cd6b193f6f74f3dbe3b7c8004884152~mv2.jpg/v1/fill/w_600,h_396,al_c,q_80,usm_0.66_1.00_0.01,enc_avif,quality_auto/%5BAdvance%20Factoring%5D%20BFF.jpg)
The UX decision was to keep these requirements inside one validation process rather than exposing eight independent workflows.
Complete operational Factoring flow map.
11. Designing the Operation as a State
The system treats the operation as a changing state. Validation, approval, confirmation and closure are not isolated screens; they are states and decisions in the lifecycle. •Created / registered •Under review •Validation •Approval or rejection •Client confirmation •Completed / closed Advance requests are handled as a parallel financial action. The documented flow keeps the advance visible and editable without forcing it to change the main operation state.
12. Product Design Decisions
The system treats the operation as a changing state. Validation, approval, confirmation and closure are not isolated screens; they are states and decisions in the lifecycle. •Created / registered •Under review •Validation •Approval or rejection •Client confirmation •Completed / closed Advance requests are handled as a parallel financial action. The documented flow keeps the advance visible and editable without forcing it to change the main operation state.
CHALLENGE
Design response
Eight validation scenarios
One reusable validation process with independent debtor-type configurations
High information density
Structured hierarchy, cards, tables and persistent context
Conditional requirements
Dynamic checklist based on business rules
Operational state changes
Explicit status, actions and history
Advance can occur at different stages
Keep advance visible and editable as a parallel process
Role complexity
Separate user access from validation logic
13. Design System
The design system translated the validation architecture into reusable interaction patterns. •Validation cards •Checklist states •Status badges •Financial tables •Forms •Alerts and risk messages •Confirmation dialogs •Filters and search •Notifications •Operation history
