# Fraud controls shipped without UX are just breaking changes

**URL:** <https://community.rapyd.net/t/fraud-controls-shipped-without-ux-are-just-breaking-changes/60060>\
**Category:** General\
**Tags:** open-discussion\
**Created:** [January 21, 2026, 4:43pm UTC](https://community.rapyd.net/t/fraud-controls-shipped-without-ux-are-just-breaking-changes/60060 "2026-01-21T16:43:09Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![drew.harris](https://sea2.discourse-cdn.com/flex016/user_avatar/community.rapyd.net/drew.harris/32/1259_2.png) [@drew.harris](https://community.rapyd.net/u/drew.harris)\
**Post date:** [January 21, 2026, 4:43pm UTC](https://community.rapyd.net/t/fraud-controls-shipped-without-ux-are-just-breaking-changes/60060/1 "2026-01-21T16:43:09Z")

</div>

Most fraud systems launch like this:  
“Ship strict rules now, deal with complaints later.”

That’s equivalent to deploying a breaking change and calling it security.

**Takeaway:** Fraud detection is part of the user interface, even if it lives in backend services.

**Framework: Intervention Layers**  
Think of fraud responses as fallbacks:

1. **Invisible** – auto-resolve using context
2. **Low-friction** – quick user confirmation
3. **High-friction** – manual review or hard blocks

**Question for the community:**  
Which layer do your current controls default to, and why?