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.
Airbnb Payments · Guidehouse AI Studio · 2026
Overview
A months-long process buried in Excel — reframed as a product
Airbnb Payments issued an RFP to modernize their annual AML/sanctions risk assessment. The existing process took months: manually fill spreadsheet questionnaires, calculate inherent risk, assess controls, derive residual risk, draft a 60-page report. By the time it shipped, the data was already stale.
Guidehouse had two weeks to respond. I led the design that turned a dense regulatory workflow into a product vision credible enough to anchor the proposal — and compelling enough to carry the oral presentation.
The Context
Translating a BSA/AML compliance methodology into a product — under a tight RFP deadline
Airbnb Payments needed more than process improvements — they wanted to know what a modern BSA/AML risk platform could look like. Guidehouse responded with a proposal and prototype built in roughly two weeks. The brief was deliberately loose: show the art of the possible.
- Role
- Lead Product Designer, AI Studio
- Timeline
- 2-week RFP sprint, Q1 2026
- Team
- FCRC SMEs, 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. Risk assessment in AML has a specific logic: define methodology and thresholds → assess inherent risk across categories (customer, geography, products, delivery channels) → assess control effectiveness → calculate residual risk. Every number on every screen had to reflect that math, or the SMEs would dismiss the prototype as theater.
Working sessions with the FCRC team extracted three things:
- The data model — what drives each risk score, and which inputs could realistically come from Airbnb's systems vs. manual entry
- Two distinct user modes — governance users configure the model once; monitoring users live in it quarterly. These needed to be separate experiences, not a single mega-flow
- The “dynamic” thesis — trigger-based refreshes, scenario simulation, and live dashboarding rather than static annual reports
That split — configuration vs. monitoring — became the spine of the entire prototype.
Configuration
One-time setup, not ongoing friction
A three-step wizard frames governance as a finite task. The 10–15 minute time estimate signals to risk leaders that this isn't another platform that will consume their quarter.
Landing — framing setup as a bounded task
Step 1 — define risk categories and weights
Step 2 — configure assessment questions
Step 3 — review and activate
Dashboard
The operational home
Three cards answer the only questions a risk officer needs to glance at daily: inherent risk, control effectiveness, residual risk. The heatmap below earns its space by showing weighted math transparently — every row reconciles to the weighted total, which was non-negotiable for SME credibility.
- Risk alerts sit at the bottom — the event-driven layer that makes this dynamic rather than annual
- Negative control effectiveness values render as explicit mitigants, with an inline formula so the logic is self-evident on screen
- Compliance reviewers verify the math on first look — any inconsistency would tank trust in the prototype
Scenario Analysis
The screen that carried the pitch
A split-view lets a user clone the baseline configuration, change any weight or assumption, and immediately see how the risk profile shifts. The comparison view surfaces deltas with directional indicators — green for risk decreasing, red for deterioration.
For a proposal audience, this answered the implicit question: what does a “dynamic” risk assessment actually feel like? You could demo it in 45 seconds.
Run Assessment & Reporting
Closing the loop
A lightweight execution flow — on-demand or scheduled — ends in a report view the client would recognize: executive summary, heatmap, key observations, export-ready. This was the bridge between the modern product and the regulatory artifact Airbnb still has to produce.
Configure — scope and schedule
Progress — real-time status
Complete — confirmation state
Report — export-ready output
Key Design Decisions
The calls that mattered more than they look
- Dashboard before configuration in the demo order — The natural build order is config → run → dashboard. The natural demo order is dashboard → scenario → config. Leading with the payoff meant reviewers saw value in the first 30 seconds
- Negative control effectiveness values — Controls reduce risk, so they render as negative mitigants. I added inline legends and a visible formula (Residual Risk = Inherent Risk – Control Effectiveness) so the logic was self-evident on screen, not buried in a methodology doc
- Heatmap totals reconcile visibly — Every weighted column sums to the total shown at the bottom. Compliance reviewers verify the math on first look — any inconsistency would tank trust in the prototype
- Restraint on the “AI” framing — The ask could have tipped into AI chatbot gimmicks. Enterprise and federal audiences read that as noise. The product is AI-informed where it earns it — explicit about human judgment everywhere else
What this project delivered
- Translated a BSA/AML compliance methodology into a two-mode product structure that held up under SME scrutiny
- Designed for a proposal audience and an end-user simultaneously — screens demoed well and reflected realistic operational use
- Anchored Guidehouse's RFP response and carried into oral presentations for Airbnb Payments
- Turned a months-long Excel-bound process into a navigable, data-driven platform within a 2-week delivery window
- Became a reusable internal template for FCRC and AI Studio modernization pitches
- Balanced aspiration with realism — dynamic event-driven vision scoped to Airbnb's near-term constraints
Reflection
Domain translation is the hardest part
The RFP deadline was real, but deadline management wasn't the skill being tested. The harder problem was entering a BSA/AML compliance domain with no prior exposure and producing work that financial crime SMEs trusted enough to put in front of a client.
The configuration vs. monitoring split was the right structural call. Once the two user modes were clear, every screen had a home. Finding that load-bearing structure — before touching the canvas — is what separates a prototype that reads like a product from one that reads like a deliverable.