BSA/AML Risk Assessment — Airbnb Payments
Designed an end-to-end BSA/AML risk assessment platform for Airbnb Payments in response to a regulatory modernization RFP — translating a months-long, Excel-bound compliance process into a dynamic, data-driven product vision.
Guidehouse AI Studio – Financial Services · Airbnb · 2026
Overview
Two weeks. No domain experience. A brief that said “show the possible.”
- I had two weeks, no prior BSA/AML experience, and a brief that said: show the art of the possible
- The existing process: months of spreadsheets, manual scoring, a 60-page report compiled by hand
- My job was to translate a compliance methodology I had never seen into a product vision credible enough to anchor a formal RFP response
The Context
Deliberately loose brief, real compliance scrutiny
- I walked in without a requirements doc. The brief was deliberately loose: show what a modern BSA/AML risk platform could look like
- No user research access. No prior financial crime background. Just working sessions with FCRC partners and a live RFP deadline
- The stakes: formal Q&A cycles and an oral presentation with Airbnb Payments — domain experts who would catch anything that missed the methodology
- Role
- Lead Product Designer, AI Studio
- Timeline
- 2-week RFP sprint, Q1 2026
- Team
- FCRC Partners & Directors, AI Studio PM, Design Lead
- Type
- Enterprise FinTech · BSA/AML Compliance · RFP Response
The Work Before the Design
Decoding a methodology-heavy domain
The first week wasn't design. It was decoding. I had to understand BSA/AML risk assessment well enough to design screens that financial crime experts wouldn't dismiss — without any prior exposure to the domain.
I ran working sessions with FCRC partners to extract the underlying logic: define thresholds, score inherent risk by category, evaluate control effectiveness, derive residual risk. Every number on screen had to reflect that math — domain experts would dismiss anything that didn't.
Those sessions gave me three things I needed to start designing:
The data model
What drives each risk score, and which inputs can come from Airbnb's systems vs. manual entry
Two user modes
Governance users configure once. Monitoring users live in it quarterly. Two separate experiences.
The dynamic thesis
Trigger-based refreshes, scenario simulation, and live dashboarding instead of static annual reports
Naming the governance vs. monitoring split was the unlock. Before I had that frame, I couldn't decide what anything was for. Once I had it, every screen had a home. I was the only person converting those sessions into designs — under a live RFP deadline, in a domain I had never touched.
Configuration
Making setup feel completable
Governance users only touch this platform during annual assessments. The risk was designing something that felt like enterprise onboarding — another tool they'd have to maintain. I needed setup to feel like a bounded task with a clear end.
I landed on a three-step wizard. The 10–15 minute estimate on the landing screen isn't UI copy — it's a promise about scope. Configure once, leave it. That became the whole governance model.
Setup landing
Risk categories & weights
Assessment questions
Review & activate
Dashboard
Earning trust through visible math
The challenge: surface complex weighted calculations in a way compliance professionals would immediately trust.
- I structured it around one question — where does the risk stand right now? Three cards answer it: inherent risk, control effectiveness, residual risk
- The real challenge was the heatmap. Compliance reviewers verify that weighted columns sum correctly before they accept any conclusion — I made every column reconcile to the total below it
- Risk alerts at the bottom make it a live operational view, not just an annual snapshot
- Negative control effectiveness renders as explicit mitigants, with the formula visible on screen
Scenario Analysis
The screen that carried the pitch
The scenario screen started as a single form where users would adjust weights and submit. That didn't work — you couldn't tell what changed or by how much. I split it into a baseline panel and a modified panel so the comparison was always visible.
- The split-view keeps the original risk profile on screen as you adjust — the delta is the whole point
- Changes surface as directional indicators: green for improvement, red for deterioration
- For a proposal audience, this made “dynamic risk assessment” concrete — showable in 45 seconds rather than explainable in five minutes
Scenario split-view
Delta comparison
Run Assessment & Reporting
Restraint was the design decision
The temptation was to make this flow prominent — a multi-step wizard, progress indicators, configuration options. I pulled back. The real work happens in the dashboard and scenario analysis. The assessment run is infrastructure.
- I kept it minimal: configure scope, run, see results
- The final report format mirrors what Airbnb's compliance team already produces: executive summary, heatmap, key observations, export-ready
- That familiarity was the point. The platform had to bridge the modern product to the regulatory artifact they still have to file
Run assessment flow
Export-ready report
Key Design Decisions
The calls that mattered more than they look
Dashboard first in the demo
The natural build order is config → run → dashboard. I flipped it. Leading with the payoff meant reviewers saw value in the first 30 seconds.
Negative controls as explicit mitigants
Controls reduce risk, so they render as negative values. An inline formula (Residual Risk = Inherent Risk – Control Effectiveness) keeps the logic visible on screen.
Heatmap totals that reconcile visibly
Every weighted column sums to the total shown below. Compliance reviewers verify this on first look. Any gap breaks trust.
Restraint on AI framing
Enterprise and federal audiences read chatbot-first AI as noise. AI shows up only where it genuinely helps, with human judgment made explicit everywhere else.
Whatthisprojectdelivered
- Two-mode product structure — BSA/AML methodology translated into a clean governance vs. monitoring split that held up under SME scrutiny
- Dual audience — screens demoed well in the proposal and reflected realistic day-to-day operational use
- Anchored the RFP — the prototype I built carried Guidehouse's response through formal Q&A cycles and oral presentations with Airbnb Payments
- 2-week delivery — months-long Excel process turned into a navigable, data-driven platform
- Reusable template — became the starting point for FCRC and AI Studio modernization pitches
- Grounded vision — balanced aspiration with near-term constraints, avoiding feature theater
Reflection
Domain translation is the hardest part
The brief was show the art of the possible— a phrase that sounds like a direction but isn't one. I had to make all the scoping decisions myself: what screens to design, what flows to prioritize, what to leave out.
I had to stay credible with two audiences at once: financial crime SMEs who would dismiss anything that missed the methodology, and a proposal audience who needed to see value in the first 30 seconds. Those two things pulled in different directions.
What made it hard
- No prior BSA/AML experience going in
- Domain experts who hadn't yet decided what they wanted to see on screen
- A live RFP proposal — formal Q&A and oral presentation stakes
What unlocked it
- Naming the configuration vs. monitoring split — every screen had a home
- Reviews shifted from what to show to how to show it