Riding the Regulatory Wave Through Your Design System

The MiCA transition period ends on June 30, and from July 1 providing crypto-asset services without a licence becomes a breach of EU law. This specific deadline affects only a small part of the financial sector, but it illustrates a broader pattern. DORA, the AI Act, and the European Accessibility Act (EAA) are all cases where regulation increasingly reaches into the product's user interface – not only the warnings, disclosures, and justifications of decisions, but the very structure of the interface itself. This is often addressed after the fact, bolted on to a finished product, yet this becomes harder to sustain the more people work on it. It may be more sensible to treat compliance as a maintained element of the design system, keeping the work of following regulation continuous.

The regulation known as MiCA (Markets in Crypto-Assets) has been entering into force gradually since the end of 2024. Providers operating before December 30, 2024 were granted a transitional grandfathering period, the length of which could vary by member state, though its final deadline is uniformly July 1, 2026. In many countries, the practical deadline has already passed; on July 1, the last grace-period window closes across the entire union. After that, providing crypto services without a license will be an EU-wide violation, and the European Securities and Markets Authority (ESMA) has made clear that there will be no extension.

MiCA itself consists largely of obligations that concern the interface. A mandatory whitepaper, warnings setting out the risks of crypto-assets, the identifiability of the provider and the product – these all appear on the user interface at the point where the customer makes their decision. The letter of the rule thus inevitably turns into a design question: where, in what form, and how understandably a user sees a warning.

The effect is already visible. Regulated European exchanges removed the non-compliant USDT stablecoin from their offerings, while the compliant USDC stayed. From the user's side, this simply meant that one asset disappeared from the list of available options. Few cleared the bar. By market estimates, around 3,000–4,000 providers were active in the European crypto market at the end of the transition period, and only roughly 200 of them obtained a license from an EU authority. The stakes are not trivial: even Binance, the world's largest crypto exchange, failed to secure an EU license in time, and for now it remains unclear whether it can continue operating in Europe. This shows clearly what a regulation means for those who fail to prepare for it in time: it can even cost them their market presence.

It's Not Just About Crypto

MiCA has a narrow scope. It covers crypto-asset service providers and token issuers, but it is far from covering everything that moves in the crypto space. Purely unique digital assets (NFTs) and services that run automatically, without an intermediary (DeFi), for instance, fall outside it. A banking executive might reasonably ask what this has to do with them if their company doesn't deal in crypto. But MiCA is just one element of a larger series, alongside DORA, the AI Act, and the EAA.

DORA regulates operational resilience and has applied since January 17, 2025. It mandates the management of risks in banks' IT and communications systems (ICT), and the mandatory, tightly time-bound reporting of serious incidents. Much of this happens in the background, but the logic is the same: documented, testable, accountable processes, not one-off solutions. It has a bearing on the interface too – outages, limited operation, and the communication of fallback processes all require designed states, not improvisation.

The European Securities and Markets Authority (ESMA) has made clear that there will be no extension

The EU AI Act (Regulation 2024/1689) follows a risk-based logic and places AI used for creditworthiness assessment in the high-risk category. This brings transparency and human-oversight obligations, much of which will be visible on the interface. It must be possible to show why a decision was made, the option of human review must be ensured, and the system must let the user understand and contest the result. For a rejected loan application, this is the difference between the customer receiving a plain rejection message and receiving an understandable, properly documented justification.

The EAA has applied since June 28, 2025, and extends to consumer banking services, websites, mobile applications, payment terminals, and ATMs. This is the most conspicuously interface-level rule: the screens concerned must be perceivable, operable, understandable, and robust, and the language used may not exceed a defined level of complexity.

What these rules have in common is that each takes shape on the product's user interface: in a warning, in a clearly worded disclosure, in an accessible form field, in a confirmation step, in the justification of a decision. Compliance thus becomes not only the remit of the legal department but a product-design task as well.

The Dead End of Bolting It On Afterwards

The common reaction in such cases is to try to bolt compliance onto the finished product. A warning into this flow, a consent step into that one, an informational text into another. Anyone who has worked on deadline-driven product development knows this, and in the short term it works.

At most financial organisations, compliance moves in its own lane: the legal and compliance side defines what's mandatory, and the product tries to satisfy it – flow by flow, on deadline, separated from the design system. The principle that recurring elements are best handled in one place is familiar, yet compliance elements rarely live under the design system's stewardship. This is where the gap opens between intention and practice.

The problem shows up at scale. If the same compliance element has to be built by hand into 20 flows, that produces 20 implementations that differ in small ways. This is the source of drift – the way the intended solution and the actually delivered interface move apart over time. It is also the source of unauditability – when a regulation changes, there is no single point where the change, once made, takes effect everywhere; instead you have to chase it down in a dozen places. And the stakes are highest precisely where inconsistency is least permissible.

Compliance Belongs in the Design System

Here another path presents itself: treating the compliance element as part of the design system. The risk warning, the consent pattern, the confirmation screen, the error message, the mandatory disclosure can all be defined, documented, and versioned components that live in one place and reach every interface from there. This makes compliance elements just as maintainable as any button or form field.

To give a concrete example: the risk warning can be a single component whose content and severity level are parameterisable, whose visual appearance and behavior are fixed, and which comes with documentation of which legal requirement it satisfies. When a product designer drops it into a new flow, they don't rewrite the text or invent a new layout; they call in the same element and fill in its parameters. Twenty instances across 20 flows, but from a single source, with identical logic. If the wording of the warning needs to change, that happens in one place and spreads from there.

One Source, the Same Everywhere

This has two practical benefits. One is consistency. If the element comes from a single source, then across a 100 developers and a dozen products it looks and behaves the same, regardless of who built it in and when. The other is auditability. If a rule changes, the modification can be made at one point and spread from there to every interface. Compliance becomes demonstrable, because it's documented which component satisfies which requirement and when it was last updated. For a supervisory question, this is the difference between having a precise, traceable answer and having to go through 20 screens one by one, hoping none was missed.

If the same compliance element has to be built by hand into 20 flows, that produces 20 implementations that differ in small ways

Compliance, moreover, is rarely static. Requirements get refined, deadlines sharpen in stages, supervisory interpretations shift. If every compliance element lives scattered across the code, then every such movement is a separate project. But if they live in the design system, in a maintained layer, then following regulation remains continuous work made of small steps, not recurring firefighting.

This approach also sorts out the lines of responsibility. If compliance elements are part of the design system, then they have an owner. The compliance and legal department no longer flags the gap after the fact as a bug ticket, but becomes a contributor to the component's definition. The requirement goes into the component's documentation, and design works from there. Between law and design, then, there is no one-way handoff but joint maintenance in a single place – which closes the communication gap that is one of the main sources of drift.

What AI Amplifies

For this, though, the design system has to be clean. We discussed this in our earlier interview with TJ Pitre, founder of Southleft: when a pattern has to be built by hand into every flow over and over, drift is practically guaranteed. The direction that points toward a solution is what he calls an AI-ready design system – a system in which the states, variants, and rules of components are documented so precisely that compliance elements also live within it as clear, governed units, rather than as scattered ad hoc solutions.

The "AI-ready" label here is not decoration. As the assembly of interfaces increasingly happens with machine assistance, the cleanliness of the system is either upgraded or downgraded. If the compliance components are precisely defined, AI can reliably put them in place and build only from predetermined, approved elements. But if drift is already present in the system, machine assembly doesn't fix it – it amplifies and multiplies it, precisely where the stakes are highest: at compliance. The regulatory wave and generative interfaces thus demand the same thing: an orderly, maintained underlying system.

The Next Rule Is Already on Its Way

MiCA is the current concern, but the line continues. The AI Act's obligations for high-risk systems sharpen in stages, and the regulation of payment services continues as well. These all bring further compliance elements to the interface. Their effects add up: if each rule is handled separately, with an ad hoc solution, the compliance elements gradually become opaque, and every new requirement increases the maintenance burden.

Everyone has to comply sooner or later. The difference is whether building in the next requirement is a single, well-defined piece of work or post-hoc rework started over each time. Regulatory expectations already touch most financial products, and they are accumulating; the design system is the place where they can stay under control.