01 Business & customer problem
"Remitly's compliance system was built to catch bad actors. Over 10 years, it had quietly become a wall for good ones."
For a decade, Remitly managed regulatory risk the same way most fintech companies do: static dollar thresholds, a document collection queue, and a 48-hour review window. If you tried to send more than a fixed amount, you got blocked. Full stop.
The system worked as designed. It also failed as designed because it made no distinction between a high-risk customer and a loyal sender who'd been using Remitly for five years and just hit an arbitrary number. By the time I joined the project, the funnel data was damning.
The compounded math: fewer than 1 in 5 blocked customers successfully sent money. The rest churned, sent less, or left. And the customers this system hurt most were exactly the ones Remitly needed most — high-amount senders who represent the vast majority of the company's revenue.
Tier Limit deprecation was the mandate to fix this. My job was to translate a compliance framework overhaul into a customer experience that removed friction for good customers while strengthening scrutiny for genuinely risky ones. That meant designing for risk, not just for users.
Problem
35%
Customers who open an application when blocked
70%
Of those who open, actually complete it
70%
Of completions that get approved
02 Context & constraints
10 years of blunt thresholds — and why they finally had to go
Remitly's Tier Limit system was a product of an era when the safest compliance posture was maximum caution. Every customer who crossed a cumulative send threshold — say, $10,000 in 180 days — had to submit a formal application: proof of identity, proof of address, proof of funds, challenge questions. Agents reviewed each one. The queue ran 48 hours.
It was defensible as a risk control. It was indefensible as a customer experience. And as Remitly scaled to 170 countries and millions of senders, the cracks became impossible to ignore.
Regulatory pressure
Financial regulators were moving toward risk-based approaches to EDD. Static thresholds weren't just inefficient — they were becoming outdated compliance methodology. A system that treated all customers equally was, paradoxically, less compliant than one that calibrated scrutiny to actual risk.
User experience failure
The post-submit block was the worst possible moment to introduce friction. Customers had already committed to a transfer — entered an amount, chosen a recipient, confirmed their payment method. Being stopped at that point, then told to wait 48 hours, produced predictable behavior: abandonment and a support ticket.
Revenue concentration risk
High-amount senders generate an outsized share of Remitly's revenue and they were the customers most likely to hit thresholds. Every churned high-sender wasn't just a lost transaction; it was a lost relationship with the company's most valuable segment.
The constraints I was designing within were significant. I couldn't change the regulatory requirement to conduct enhanced due diligence, that was fixed. We couldn't make the CRR model real-time; it ran on a 24–48 hour batch cycle and that was an engineering constraint compliance had formally accepted. And we couldn't launch everywhere at once — Australia was the test region, and the global rollout depended on what we learned there.
With EDD 2.0, we were trying to make it easier for our customers to send more money while strengthening our risk-based EDD framework - easier for customers, stronger for compliance. Not a trade-off. Both, at once. The architecture that made it possible was the Customer Risk Rating model — a weighted score calculated from customer and transactional attributes that replaced the blunt dollar threshold with something that actually knew the difference between a legitimate high-sender and a genuine risk.
03 My role
Lead designer — customer experience and the hardest UX problem
I was the design lead for the customer-facing experience on EDD 2.0, working alongside a PM, 4 engineers, a compliance lead, and a CS program manager. The project had five cross-functional review tracks — Compliance, Product, Engineering, Send Team, and Customer Success — all of which had approval rights over what shipped.
-
The full customer-facing send flow — both the optional pre-collect state and the mandatory collection gate, designed as distinct experiences with different emotional registers.
-
The challenge question (CQ) UX — a critical open problem inherited at the start of the project: 50%+ of customers were providing unstructured responses to occupational questions, which was triggering false-positive EDD reviews at scale.
-
Cross-functional alignment between Design and Compliance on the CQ structured data solution — I co-owned this dependency with the compliance team and drove it to resolution.
-
The information architecture of the two-state collection flow: how to make "optional" feel genuinely optional, and "mandatory" feel fair rather than punitive, within the same product surface.
What I was not responsible for: the CRR model itself (Risk Analytics), the agent-facing CRM queue design (Risk Tools), and the engineering implementation of the risk scoring pipeline (Engineering). Knowing those boundaries mattered — this was a project where scope creep in any direction would have slowed a compliance-gated launch.The most structurally complex part of my role was the challenge question problem. It wasn't in the brief when I started. It surfaced as a risk item midway through: compliance had flagged that a significant share of customers who completed EDD questions were responding to "What is your current occupation?" with answers that didn't map to any recognized category — triggering an agent review even for customers who had no other risk signals. The system was producing false positives at volume because the free-text input couldn't be evaluated reliably. I owned the design solution to that problem, and I'll cover it in detail in the process section.
04 Discovery & framing
What the data revealed — and the problem hiding inside the problem
Discovery on this project wasn't primarily user research. The problem was already well-documented in funnel data, CS escalation logs, and a decade of internal post-mortems on Tier Limit performance. My job in the discovery phase was to understand why the system had been designed the way it was — and to find the places where design decisions, not just policy decisions, had made things worse.
Three things discovery confirmed
Most customers weren't risky
The CRR model data showed that roughly 70% of customers who hit the old thresholds were low-risk by any measurable attribute. They were being subjected to maximum friction not because of anything they'd done — but because they'd sent enough money to cross a number that hadn't changed in years.
The agent queue was a symptom
Tier limits were the second-highest volume back-office queue at Remitly, representing 28% of task volume. The problem wasn't just customer-facing — it was operational. Duplicate applications, inefficient triage, and unclear case ownership were signs of a system that had scaled past its design capacity.
The problem hiding inside the problem
Midway through discovery, a risk item surfaced that hadn't been in the original brief. Compliance flagged that more than 50% of customers who completed EDD challenge questions were responding to "What is your current occupation?" with answers that didn't map to any structured category. Free-text. Unclassifiable. The system had no reliable way to evaluate these responses — so it flagged them all for human review.
Key insight: The EDD review queue wasn't filling up because customers were risky. It was filling up because the input design made it impossible for the system to tell the difference. We were generating false positives at scale — not from bad policy, but from bad UX.
This reframed the scope of my work. The customer flow was one design problem. The challenge question structure was another — and it was the one most likely to determine whether EDD 2.0 actually reduced agent workload or simply moved the bottleneck around. I co-owned that dependency with Compliance and it became a central thread in the process.
05 Strategic design bets
The non-obvious calls — 2 decisions that weren't prescribed
The compliance requirements told us what had to happen. They didn't tell us how, when, or in what emotional register. These were the design decisions that required making a call, building a case, and getting the room aligned.
Bet 1: Design two distinct states — optional and mandatory — rather than one escalating flow
Compliance instinct:
One collection flow that activates at the mandatory threshold — clean, easy to build, one surface to maintain.
Design argument:
An optional early-collection state gives low-risk customers a graceful on-ramp. It also reduces the volume of customers hitting the mandatory gate all at once, smoothing the agent review queue.
The PRD defined two distinct trigger thresholds per risk tier: an earlier "information requested" threshold and a later "information required" threshold. Most design approaches would have treated these as one flow with a softer and harder variant of the same screen. I pushed for them to be genuinely distinct experiences — different copy register, different call-to-action, different consequence framing. "Provide details or remind me later" versus "provide details to finish your transaction" are not the same ask, and designing them identically would have eroded trust in the optional state. The CTA copy alone required three rounds of alignment with Compliance and Legal.
Bet 2: Replace free-text occupation input with structured response options
Compliance instinct:
Status quo: free-text field for "What is your current occupation?" — maximum flexibility for the customer, but unclassifiable at scale.
Design argument:
A structured input — dropdown or multi-select with defined categories — maps directly to the CRR model's evaluation logic and eliminates the false-positive pipeline.
This was the highest-stakes design decision I made on the project, because it required convincing Compliance to change a data collection standard — not just a UI pattern. The argument was systematic: free-text responses couldn't be reliably evaluated, which meant they were defaulting to human review, which meant the new EDD queue would inherit the same operational overload as the old Tier Limit queue. A structured input was the only way to let the system — rather than an agent — determine whether a response was usual or unusual. I presented the problem statement to Compliance as a design+data document, not a UX preference, and we reached alignment on a structured approach.
06 Cross-functional leadership
How alignment actually got built — across 5 review tracks
EDD 2.0 had five cross-functional review tracks with formal approval rights: Compliance, Product, Engineering, Send Team, and Customer Success. In practice, this meant that every significant design decision had at least two non-design stakeholders who could block it — and several decisions required alignment across all five simultaneously.
The cross-functional work I'm most proud of isn't the big alignment moments. It's the smaller ones that prevented bigger problems: the CS program manager conversation that surfaced the queue volume spike risk early enough to influence the threshold design; the engineering constraint discussion that made CRR batch latency a design input rather than a late-breaking limitation; the compliance working session that turned the CQ structured input from a design preference into a shared compliance instrument.
The hardest alignment moment — Occupation question structured input
Compliance owned the challenge question requirements. The existing requirement called for a free-text response — it was how EDD information had always been collected. My argument was that free-text collection was producing a false-positive pipeline that would make EDD 2.0's agent queue as unmanageable as the Tier Limit queue it was replacing. I wasn't asking Compliance to weaken the requirement. I was asking them to change the collection method in a way that would make the requirement more enforceable, not less.
The reframe that unlocked alignment: I stopped presenting this as a UX problem and started presenting it as a data quality problem. The PRD itself documented the risk: "more than 50% of customers do not provide structured data responses to challenge questions." That number had a compliance cost, not just a UX cost — it meant agents were reviewing cases that the model couldn't evaluate, consuming SLA budget on responses that weren't actually unusual. When I put it that way — as a compliance risk, not a design preference — the conversation shifted from "should we change this?" to "how should we structure it?"
What I brought to the room:
A written problem statement reframing the CQ issue as an operational risk with a documented false-positive rate. A proposed structured input with draft category options mapped to the CRR model's evaluation logic. A clear articulation of what "unusual" would mean in a structured vs. free-text context.
What changed as a result:
Compliance agreed to move to a structured collection format. The final design was co-developed across design and compliance — the category definitions were a joint artifact, not a design handoff. This made the final solution more durable: it had regulatory legitimacy, not just UX logic.
07 Final design
What shipped — and the decisions behind every screen
The final EDD 2.0 customer experience comprised two distinct collection states, both inserted as checkpoints between Step 1 and Step 2 of the send flow — pre-submit, contextual, with the transaction visible so customers understood what they were completing and why.
State 1 — optional collection (proactive request)
The optional state was designed to feel like an invitation, not a warning. The customer had not yet reached the mandatory threshold — they were being given early access to a process that would eventually be required. The "remind me later" option was genuinely consequence-free at this stage, which meant the copy had to be honest about that. Several rounds of legal review went into making the language accurate without being alarming.
State 2 — mandatory collection (information required)
The mandatory state required a different design logic. The customer's transaction was now dependent on completion — that was a fact the UI had to communicate clearly, without triggering the abandonment behavior we'd seen in the old post-submit block. The key decision was showing the transaction details prominently in the collection flow: amount, recipient, estimated delivery. This gave customers a concrete reason to complete, rather than abstract compliance language about why information was required.
The structured occupation question input
Three challenge questions, asked in sequence: reason for sending, source of funds, current occupation. The first two had always been structured. The third — occupation — was the one that had been generating false positives at scale. The structured input replaced the free-text field with a defined set of categories co-developed with Compliance, mapped directly to the CRR model's evaluation taxonomy. A customer selecting a standard category received an automatic pass on that question. Only responses that didn't fit any category — or that combined with other unusual signals — would route to agent review.
System contribution — a reusable collection pattern
Beyond the two collection states, this project produced a reusable design pattern: a pre-submit checkpoint that could hold any compliance-required information request without disrupting the send flow. The pattern was documented and added to the design system — it was subsequently used for the PayTo payment method integration and referenced in the Japan market expansion work. That kind of system contribution is what makes a single project's impact compound over time.
08 Outcomes
What changed — in numbers, in operations, and in the system
The final EDD 2.0 customer experience comprised two distinct collection states, both inserted as checkpoints between Step 1 and Step 2 of the send flow — pre-submit, contextual, with the transaction visible so customers understood what they were completing and why.
Problem
35%
Of revenue from high-amount senders
The segment we optimized for — now moving through the send flow without a post-submit block
70%
Of customers fully unblocked
Low-risk customers classified by CRR — no EDD interruption, no threshold friction
$100K USD
Largest single transfer enabled,
A send-to-self transaction — the kind the old system had no architecture to handle gracefully
Impact 01 — Customer
From post-submit block to pre-submit context
Moving document collection earlier in the flow removed the moment that generated the most abandonment, confusion, and support contacts. Customers now encounter EDD as part of the send process — not as an interruption to it. The emotional register shifted from "you've been stopped" to "here's what we need to continue." The completion rate for pre-submit collection exceeded the old post-submit application completion rate — customers who understand why they're being asked are more likely to comply than customers who've just been blocked.
Impact 02 — Revenue
High-amount senders unblocked at scale
High-amount senders represent 29% of Remitly's revenue, and they were disproportionately affected by the old threshold system — their transaction sizes meant they hit limits more often and faced the most friction. EDD 2.0's CRR-based approach meant that a loyal, low-risk high-sender would now move through the flow without interruption. The largest transfer enabled through the new architecture was $100,000 — a send-to-self transaction that would have been blocked and queued for manual review under the previous system.
Impact 03 — Compliance
A stronger framework, not just a lighter one
EDD 2.0 didn't reduce compliance scrutiny — it redirected it. By removing friction for the 70% of customers who were genuinely low-risk, the system concentrated review resources on the customers who actually warranted them. The structured CQ input reduced the false-positive pipeline, which meant agent time was spent on genuine cases rather than on unclassifiable free-text responses. The result was a compliance posture that was simultaneously more defensible to regulators and less burdensome to customers.
Impact 04 — Operations
The agent queue problem addressed at the source
Tier limits had been the second-highest volume back-office queue at Remitly, representing 28% of task volume. The redesign attacked that volume problem in two ways: fewer customers entering the queue (because CRR-based routing excluded low-risk customers) and fewer false-positive cases consuming agent time (because structured CQ responses could be evaluated systematically). The proactive collection state also smoothed queue spikes by distributing review load across a longer window rather than concentrating it at anniversary thresholds.
09 Reflection
What I'd do differently
EDD 2.0 shipped. The architecture held. But 3 things sit with me.
I'd involve engineering earlier in the CQ solution. The structured input work was primarily a design-and-compliance conversation. Engineering was brought in later to scope implementation. In hindsight, earlier engineering involvement would have surfaced constraints on how the structured categories could map to the CRR model's back-end taxonomy — constraints that affected the category definitions and required a late-stage revision. Compliance and design alignment without engineering alignment isn't full alignment.
I'd push harder for real-user testing on the optional collection state. The two-state architecture was validated through stakeholder review and internal critique, but not through sessions with actual Remitly customers. The "remind me later" framing tested well with the team — but we didn't know whether customers who deferred proactive collection understood that the information would eventually be required. If the deferral created surprise at the mandatory threshold, we would have inadvertently recreated the abandonment problem we were trying to solve. I believe the design worked, but I don't have the data to prove it.
I'd document the design system contribution more explicitly at the time. The pre-submit checkpoint pattern was reused in two subsequent projects, but the connection wasn't formally documented until later. If I'd made the system contribution explicit — named it, wrote it up, added it to the design system with attribution — it would have been easier to reference in the global rollout work and would have accelerated the subsequent integrations. Shipping a reusable pattern that only you know about isn't really shipping a reusable pattern.
What this project reinforced for me: the hardest design problems in fintech aren't visual. They're structural — about when in a flow to ask for something, how to frame an obligation as an invitation, and how to make a compliance instrument legible to a person who just wants to send money home. The design decisions that matter most in this space are the ones that happen in working sessions with compliance leads and CS program managers, not in Figma. Getting comfortable in those rooms — and knowing how to translate between regulatory language and UX logic — is the skill that makes the work possible.