AI Decision Support
Boundary1
Designing a compliance and reimbursement platform for borderless teams
Boundary1 is a concept for a B2B platform that helps global companies validate expense documents, manage residency-related compliance risk, and move reimbursements faster across borders.
I designed it as a first-generation platform foundation spanning submission, validation, exception routing, and payout visibility across employee and finance workflows. The project improved operational structure, but also exposed an important limitation: more accurate automation did not automatically make the system easier to understand in moments of uncertainty.
Project Snapshot
| Area | Details |
|---|---|
| Project | Boundary1 |
| Type | Concept case study |
| Category | Platform product design / B2B fintech / compliance operations |
| Timeline | October 2025 - December 2025 |
| Primary users | Finance leaders, accountants, remote employees |
| Problem space | Cross-border reimbursements, Factur-X compliance, residency risk, payout trust |
| My role | Product Designer |
| Scope | Research, workflow design, system modeling, prototyping, UI |
Why this was a platform problem
Boundary1 was not just an expense tool. It required a shared operational system across multiple actors, rules, and infrastructure layers.
The product had to coordinate employees submitting expenses, finance teams reviewing exceptions, compliance logic evaluating structured tax and residency signals, and payout operations determining reimbursement outcomes.
The design challenge was to turn fragmented regulatory and operational complexity into a product that could scale across workflows, jurisdictions, and user roles.
The Problem
Global finance teams often face a tradeoff between speed, trust, and legal certainty.
Two problems collide in cross-border reimbursement workflows:
-
document compliance: finance teams cannot rely on flat OCR output when regulatory requirements depend on structured tax data such as Factur-X XML
-
employee reimbursement trust: remote workers often wait weeks to recover out-of-pocket expenses while navigating rules they do not fully understand
Existing workflows increase manual review, delay payouts, and make compliance feel adversarial. Boundary1 explored how a shared platform could reduce this burden while preserving employee autonomy.
Users and stakeholders
| Actor | Needs | Risk |
|---|---|---|
| Sarah, Head of Global Finance | Audit-ready validation, reduced manual review, visibility into compliance risk | Legal exposure, burnout, exception overload |
| Osas, Remote Engineer | Fast reimbursement, privacy, clear next steps, low submission effort | Financial strain, distrust, delayed rejection |
| Finance Ops | Structured review flows, exception visibility, reliable records | Rework, ambiguity, admin fatigue |
| Platform / Compliance layer | Consistent rule execution, traceable states, scalable workflows | Opaque automation, weak user trust |
Research Insights
I interviewed finance managers and remote engineers, observed accounting workflows using legacy tools, and reviewed regulatory constraints around Factur-X compliance.
Four patterns stood out:
1. Finance teams lacked trustworthy inputs
Legacy OCR workflows were too uncertain for high-stakes compliance tasks, forcing finance teams to manually verify what the system had extracted.
2. Employees experienced reimbursement as a trust failure
Delayed payouts created financial strain and resentment, especially when status updates were vague or slow.
3. Mobility compliance created a privacy tradeoff
Companies needed visibility into residency-related tax risk, but employees resisted continuous tracking and did not want compliance to feel punitive.
4. Better automation did not automatically feel clearer
Even when system logic improved, users still felt uneasy when decisions appeared abstract or difficult to interpret.
Platform model
Boundary1 was designed as a shared operating layer across submission, validation, risk detection, review, and reimbursement.
At a system level, the workflow looked like this:
- an employee submits a receipt
- the document enters a validation layer
- compliance logic evaluates structured tax data and residency-related risk
- the system routes the outcome into payout, review, or escalation
- both finance and the employee receive status feedback based on their role
Diagram
Core platform primitives
| Primitive | What it does |
|---|---|
| Expense intake | Captures receipts and expense submissions with minimal user effort |
| Structured validation | Checks machine-readable invoice or receipt data against compliance requirements |
| Residency-aware logic | Tracks events relevant to tax exposure without requiring persistent surveillance |
| Exception routing | Sends ambiguous or blocked cases into finance review rather than failing silently |
| Decision states | Communicates whether an item is in progress, approved, blocked, or needs action |
| Payout visibility | Gives employees clearer visibility into reimbursement timing and progress |
| Auditability | Creates a more traceable operational record for compliance and review |
Key workflows
Employee workflow
For employees, the workflow needed to feel light, fast, and non-punitive. I focused on reducing the cognitive burden of submission by making receipt capture the main action and surfacing reimbursement progress more clearly than in traditional pending-state systems.
The employee experience centered on:
-
simple receipt submission
-
visible reimbursement progress
-
lightweight residency awareness
-
less dependence on manual tax knowledge
-
clearer status feedback when something blocked payout
Finance workflow
For finance users, the system needed to reduce manual cleanup and create more confidence in what the platform was validating. I designed for a review model in which finance teams focused on exceptions, compliance risk, and oversight rather than acting as human middleware.
The finance experience centered on:
-
structured validation signals
-
exception visibility
-
review-ready compliance context
-
clear distinction between pass, review, and risk states
-
less repetitive document correction work
Key design decisions
Deterministic validation over OCR-style guesswork
A major design decision was to move away from workflows that depend on uncertain text extraction alone. In a compliance-heavy context, users needed stronger confidence that the system was evaluating the right data.
Event-based residency logic over continuous monitoring
Research showed that employees perceived persistent tracking as a breach of trust. I explored lighter-touch, event-based ways to support residency awareness without making the system feel invasive by default.
Exception-first operations model
Rather than designing for finance to manually inspect everything, I structured the product around routing only problematic or ambiguous cases to review.
Visible status over silent system behavior
I introduced stronger status cues around reimbursement and validation progress so users were not left waiting in a generic pending state. This improved feedback, but it did not fully solve interpretability in complex cases.
Selected screens
Screen 1: Employee submission / receipt capture
Screen 2: Employee reimbursement / payout status
Screen 3: Finance validation / exception view
Screen 4: Residency / compliance risk view
Screen 5: Changes I made after Feedback
Replacing abstract AI signaling with grounded validation feedback improved perceived trust, but did not fully close the explainability gap.
What worked
Boundary1 demonstrated how a more structured platform could improve the operational foundation of global reimbursements.
The concept showed promise in several areas:
-
better workflow structure between employee submission, validation, review, and payout
-
reduced dependence on manual review for straightforward cases
-
stronger compliance readiness through structured validation thinking
-
better payout visibility than traditional opaque reimbursement queues
-
less invasive compliance framing through event-based logic instead of continuous surveillance
Visible validation and payout cues improved confidence relative to abstract AI metaphors alone, especially for finance users.
Accessibility considerations
Boundary1 avoided time-sensitive interactions, reduced cognitive overhead in compliance-heavy tasks, and avoided relying on color alone to communicate key states. This was especially important in a system where trust depended on users being able to interpret complex status information clearly.
Where Boundary1 fell short
Boundary1 made the system more structured and more deterministic, but not yet fully interpretable.
Testing and reflection revealed a second-order problem: improving system accuracy did not automatically make the product feel understandable in moments of uncertainty.
The main limitations were:
-
structured validation signals
-
decision logic still felt abstract in edge cases and exceptions
-
status visibility did not always translate into confidence
-
finance and employees still lacked a complete mental model of how the system reached certain outcomes
-
automated reasoning was visible at a system level, but not always clear at a human level
In other words, Boundary1 reduced backend ambiguity, but front-end trust still lagged behind.
What I learned
The biggest lesson from Boundary1 was that making a system more accurate does not automatically make it feel more understandable.
Deterministic infrastructure improved operational certainty, but users still needed clearer ways to interpret what the platform was doing, why it made certain decisions, and what action they should take next.
Determinism is not the same as explainability.
What Boundary1 led to
Boundary1 established the operational backbone: structured validation, residency-aware logic, exception routing, and payout visibility.
But it also exposed a deeper product challenge: accurate automation can still feel opaque.
That unresolved gap became the starting point for Boundary2, where I focused on making platform reasoning more legible in moments of rejection, delay, ambiguity, and compliance risk.
