ASIC RG 268 Cross-Border Disclosure — Three UX Patterns
Three ways to surface the jurisdiction-specific warning. One of them is almost always the right answer in production.
ASIC Regulatory Guide 268 governs how Australian-licensed financial services firms handle cross-border retail clients — and specifically the point at which a non-Australian client, or an Australian client being offered a non-Australian product, is placed in front of a transaction they can still back out of. The guide requires that the client sees, and meaningfully engages with, a jurisdiction-specific disclosure before each relevant transaction. Not once at onboarding. Every time.
That "every time" is the whole design problem. Four years at ACY Securities, which holds ASIC AFSL 403863 and serves traders across 40+ jurisdictions, I watched this disclosure get designed and redesigned about six times across five platforms. Three patterns keep recurring. One of them wins in production almost every time.
Pattern A — Modal interstitial
What it looks like: The trader clicks SEND on an order. A modal blocks the screen. Red warning icon. Three paragraphs of disclosure text referencing the client's jurisdiction, the product's issuing entity, the regulator, and the PDS/TMD. "I acknowledge" button, disabled for 3 seconds. Click to proceed.
Pros: Compliance loves it. The disclosure is impossible to miss, the consent is explicit and timestamped, the legal audit trail is gold-plated.
Cons: It is the single most hated UI element on the entire platform. Traders hit it on every order. Within a week they learn to click through without reading. Within a month, compliance quietly admits the "meaningful engagement" the regulation requires has decayed into muscle memory. The modal has become friction, not consent.
Where it fits: The very first transaction after a jurisdiction change, or after a material product change. Never on every order.
Pattern B — Persistent header strip
What it looks like: A thin horizontal strip at the top of every trading screen. "You are trading with ACY Capital Australia Pty Ltd (AFSL 403863). Products are not regulated by [client's home regulator]. Full disclosure →". Always present, never interrupts.
Pros: No friction. Always visible. The disclosure is woven into the environment rather than thrown in front of the action.
Cons: After 48 hours, the strip becomes invisible to the user in the clinical sense — eye-tracking studies confirm users stop fixating on persistent top bars within two sessions. Compliance looks at it and asks, reasonably, whether an always-present strip satisfies the "before each transaction" engagement test. The honest answer is no. It satisfies the "disclosure is available" test, not the engagement one.
Where it fits: Layered alongside something more active. Not as the primary mechanism.
Pattern C — Contextual inline
What it looks like: On the order ticket itself, directly adjacent to the SEND button, a one-line disclosure synthesised from the client's jurisdiction + the product's issuer + the regulator at the moment of order building. "Trading CFD on ASX 200 with ACY Capital Australia (AFSL 403863). Product not regulated by [client's home]. Full PDS." The line updates if the client changes instrument or account. No blocking, no interruption — but the line is rendered at the exact moment of decision, in the exact place the eye is already looking.
Pros: Passes the engagement test because the disclosure is co-located with the action, not ambient. Does not accumulate friction because it is not a blocking interaction. The jurisdictional synthesis is dynamic, so edge cases — multi-entity account structures, temporary residency changes, product entity swaps — are handled in data rather than in copy variants.
Cons: It requires real engineering. The disclosure is a computed string derived from [client jurisdiction] × [product issuer] × [regulator mapping] × [relevant AFSL]. That matrix has to live in the data model, not the Figma file. You cannot ship Pattern C with a front-end copy library; you need a backend rule engine that the legal team can edit without a release.
Where it fits: As the primary disclosure surface on every order entry screen. This is the one I keep coming back to.
What production testing showed
Across three A/B-style studies I ran or advised on at ACY between 2022 and 2024, the pattern comparison came out roughly like this:
| Metric | A — Modal | B — Header strip | C — Inline |
|---|---|---|---|
| Measured read-time on disclosure | ~0.8s after week 1 | ~0.2s (glance) | ~1.6s sustained |
| Order abandonment at disclosure | 3.2% (friction) | 0.1% | 0.4% |
| Support tickets re: "what entity am I trading with" | high | high | low |
| Compliance audit readiness | strong | weak (engagement test) | strong |
| Developer cost to maintain | low | low | medium |
The inline pattern wins on the metric that actually matters — the user genuinely engaging with the disclosure — without exacting the abandonment tax of the modal. It costs more to build because the disclosure is data-driven, not copy-driven. That is the right trade.
The layered pattern I ship
In production I rarely ship a single pattern. The shape that has survived regulator conversations is: Pattern A only at material trigger points (first order after onboarding, first order after a jurisdiction change, first order after a product-entity swap) + Pattern C on every order thereafter. Pattern B is optional ambient context for the platform frame; it carries no compliance weight on its own and the legal team should not pretend it does.
Two things I argue against when this comes up in reviews. First, reusing the same disclosure copy across jurisdictions "because it is simpler." RG 268's entire point is that the disclosure is tailored; a single string fails the regulation. Second, stacking Pattern A and Pattern B and Pattern C simultaneously "to be safe." Disclosure fatigue is a well-documented consent failure mode and ASIC has explicitly cited it in enforcement actions. More is not safer. The right pattern, at the right moment, is safer.
Related work