What are the legal requirements for automotive apps?

A vehicle manufacturer once asked us to look at an accident reporting app that was quietly failing. Drivers who had just been in collisions were abandoning the process halfway through. The app simply said "upload your photos" with no indication of what angles to capture, no guidance on what the insurance company actually needed, and no acknowledgement that someone who has just had a crash is not in a calm, methodical frame of mind. The interface treated a traumatic moment as an administrative task.

Automotive apps sit at the intersection of safety law, data regulation, and the kind of high-stress human moments that bad design handles worst.

What we found underneath that UX failure was also a compliance problem. The app had legal obligations around what data it needed to collect, how it needed to collect it, and in what sequence. The interaction design and the legal requirements were pulling in opposite directions, and nobody had resolved the tension before launch.

Automotive apps occupy a genuinely difficult compliance space. They collect location data, process payments, authenticate identities, and operate in contexts where a distracted user is a safety risk. The legal requirements governing all of this are real, specific, and increasingly enforced. This article works through what those requirements are and how they translate into design and product decisions.

Driver distraction regulations

Every country with road safety legislation has rules governing what a driver can interact with while a vehicle is in motion. In the UK, the Highway Code and the Road Traffic Act make it illegal to hold and use a device while driving. The EU's General Safety Regulation, which came into force for new vehicle types in 2022, goes further, requiring that in-vehicle systems meet defined distraction standards before a vehicle can be type-approved. In the United States, the National Highway Traffic Safety Administration publishes voluntary guidelines for in-vehicle interfaces, and several states have their own hard rules on top of those.

What this means for interaction design

Practically, distraction regulations mean that any input requiring more than a glance, more than a single tap, or more than two seconds of attention is legally and ethically difficult to justify for use while driving. Tasks that require reading, scrolling, form entry, or multi-step decision-making must either be locked out when the vehicle is moving or redesigned so thoroughly that they do not need a driver's visual attention at all. Voice interfaces, accelerometer-triggered prompts, and heads-up display patterns exist partly because the distraction rules leave no other option.

The accident reporting work we did for a vehicle manufacturer came directly from this tension. The original interface expected a driver who had just stopped suddenly to navigate to a reporting section, remember what evidence was needed, and type claim details. We used the accelerometer data to detect a sudden stop after movement and proactively surface a single question: "Have you been in an accident?" That one change removed the navigation burden entirely. From there, a visual diagram of the car let users tap affected areas rather than describe them in text, and voice recording replaced typed witness statements. The compliance requirement, collecting sufficient evidence for an insurance claim, was the same. The method changed completely.

Data privacy and GDPR in connected vehicles

By 2030, TMA Solutions estimates that nearly 95% of new vehicles will be connected, up from around 50% in 2020. A connected vehicle generates a continuous stream of data: location, speed, braking patterns, fuel consumption, music preferences, destinations, and in some cases biometric readings. Under GDPR, almost all of this qualifies as personal data, and a meaningful portion of it qualifies as sensitive personal data requiring explicit consent.

Consent and data minimisation

The two GDPR principles that do most work in automotive apps are consent and data minimisation. Consent must be specific, informed, and freely given, which means a single "I agree" checkbox covering everything the app collects does not satisfy the regulation. Data minimisation means the app should collect only what it genuinely needs for the stated purpose. A parking app needs location at the time of parking. It does not need continuous location tracking between sessions, and collecting it without a clear legal basis is a breach.

The consequences of getting this wrong are not only financial. If users do not trust how their vehicle data is being used, they stop using connected features, which defeats the product purpose entirely. Designing consent flows that are honest, specific, and presented at the moment the data use becomes relevant rather than buried in onboarding is both a compliance requirement and a retention strategy.

KYC, AML, and financial compliance for in-app transactions

Automotive apps increasingly handle money. Fuel payments, parking charges, toll transactions, subscription services, and in-car purchases all route through payment layers that attract financial regulation. Know Your Customer (KYC) requirements mean verifying the identity of users before certain transaction types are permitted. Anti-Money Laundering (AML) rules mean building controls that prevent the app being used to move money in ways that obscure its origin.

We learned this the difficult way on a peer-to-peer currency exchange product we built, where users could exchange leftover foreign currency with other travellers at interbank rates. We built the core transfer mechanism well. What we did not factor in was AML compliance. Apple flagged the product as a potential vehicle for money laundering because of its unlimited transfer capability between any two parties. We had to go back and retrofit several layers: more stringent KYC checks, enhanced transfer security, and hard limits on the number of transfers permitted between specific user pairs. The rework cost time and budget that would have been far smaller had the compliance requirements shaped the architecture from the start.

Retrofitting AML controls and KYC checks after build is a significantly more expensive problem than designing for them from day one.

For automotive apps, the same logic applies. An app that allows peer payments for carpooling, cashback on fuel, or in-vehicle commerce needs to understand its obligations under the Payment Services Directive 2 in the UK and EU, and equivalent frameworks elsewhere, before it writes a single line of payment flow code.

Map every money movement in your app before you begin design. Include micro-transactions, peer transfers, and subscription top-ups. Each one carries a regulatory implication that shapes the UX.

Authentication requirements you cannot defer

The default position in most product design is to defer authentication for as long as possible. Let users explore the product before asking them to register, because every additional step before value is a reason to leave. That logic holds in many contexts. In automotive apps, it often does not.

When legal requirements override product preference

On an anonymous messaging app we worked on, we put authentication right at the front of the experience, before any user could send a message. The product was anonymous to users in the interface, meaning no one could see who had sent what. But on the back end, every message needed to be tied to a verified identity. The reason was entirely legal: if harassment or abuse occurred, we needed to be able to identify the sender and comply with any law enforcement request. Deferring authentication would have made the product legally inoperable.

Automotive apps face similar hard requirements. A telematics app that rewards safer driving must verify that the person receiving rewards is the person whose driving is being measured. A carsharing app that transfers keys digitally must know the identity of the person receiving access. An app used for insurance purposes must have auditable identity verification. In all of these cases, the legal requirement for identity certainty arrives before the product preference for a frictionless start.

The design task is making mandatory authentication feel considered rather than obstructive. Explaining why identity verification is needed, asking permission rather than demanding compliance, and sequencing the verification steps so they appear at the moment of obvious relevance rather than before any context has been established, all of these change how users experience a process that cannot be removed.

When authentication is legally required upfront, explain the reason at the point of the request. "We need to verify your identity so any reports you submit are legally valid" does more for completion rates than a blank form field.

Location data, safety, and duty of care

Location is the most valuable and most sensitive data type in automotive apps. It enables core features: navigation, nearby fuel prices, parking availability, incident detection. It also creates legal exposure across multiple frameworks simultaneously, GDPR on the data side, road safety law on the distraction side, and an emerging duty of care obligation on the safety side.

Designing location features responsibly

We worked on a social fitness app that was originally map-based, showing users' real-time locations so they could find workout partners nearby. Research revealed that a high proportion of users were female, which changed the risk profile of precise location sharing significantly. We redesigned the feature to use randomised location offsets, showing only a vague area rather than an exact position. Users could then review profiles and start a conversation before choosing to share their precise location. The core value, knowing whether a potential workout partner was close enough for a meetup, was preserved. The safety risk was not eliminated, but it was substantially reduced, and users retained control of when and whether they disclosed their exact whereabouts.

For automotive apps, the same design thinking applies to features like journey sharing, fleet tracking, and emergency location services. Sharing a driver's location with a third party, even for safety purposes, requires a clear legal basis, an explicit consent mechanism, and a way for users to revoke that consent. An app that tracks location continuously without surfacing that fact to users, or without offering a meaningful way to stop it, is a regulatory breach.

Build a location permission audit before launch. List every moment your app requests, uses, or stores location data. For each one, confirm the legal basis and the consent mechanism.

Accessibility requirements for automotive interfaces

Accessibility in automotive apps is governed by a patchwork of overlapping obligations. In the US, the Americans with Disabilities Act applies to companies with 15 or more employees and extends to digital products, including apps. The UK Equality Act 2010 creates similar obligations. The European Accessibility Act, which member states were required to implement by June 2022, covers digital services including transport applications. Web Content Accessibility Guidelines (WCAG) 2.1 at Level AA is the technical standard that most of these frameworks point to.

Accessibility and in-vehicle context

In automotive interfaces, accessibility overlaps with distraction compliance in ways that often improve both. Larger touch targets reduce the precision required to interact while wearing gloves or in a moving vehicle. High contrast ratios make displays legible in direct sunlight. Voice control accommodates users with motor impairments and also reduces visual distraction for all drivers. Designing for a user with limited dexterity produces an interface that is safer for everyone.

The risk in automotive UX is treating accessibility as a post-launch addition, something to address in a future sprint once the core product is stable. Retrofitting accessible design onto an interface built without it is substantially harder and more expensive than building it in from the start. Text contrast, touch target sizing, and keyboard or voice navigation need to be in the design brief, not the QA checklist.

How compliance requirements shape interface decisions

The compliance requirements described in this article are, in many cases, the reason certain interface decisions have to be made in a particular way. The question is whether a product team discovers that after build or before it.

Consider what compliance actually determines in an automotive app. The table below maps the main requirement areas to the interface decisions they force.

When these requirements arrive late in a project, they do not slot in cleanly. They land on top of an architecture that was not built to accommodate them, which means rework rather than refinement.

The cost of retrofitting compliance

The cost of non-compliance is estimated by Globalscape to be nearly three times the cost of compliance itself. That figure captures regulatory fines, remediation costs, and business disruption. It does not capture the design and development cost of retrofitting requirements onto a product that was not built with them in mind, which on complex automotive products adds a further layer of expense.

The dating app project we worked on illustrates the pattern clearly. The client chose to skip discovery for the messaging component and focus purely on onboarding. What that produced was a generic messaging feature that directly contradicted the product's core premise, a rigorously verified identity system undermined by a messaging layer that permitted automated and fake messages. The entire messaging section had to be rewritten. That cost approximately £15,000 in additional budget and added two months to the timeline. The compliance implications of the messaging layer, specifically the verification requirements that should have extended through the full product, were one of the things the skipped discovery would have surfaced.

In automotive apps, the stakes are higher because multiple regulatory frameworks apply simultaneously. A compliance gap in a financial layer, a data privacy gap in a location feature, and an accessibility gap in an input component can each trigger separate regulatory consequences. Addressing them before architecture is set costs a fraction of what addressing them after launch costs.

1. Map every data type the app will collect before design begins.
2. Identify the regulatory framework governing each data type and each transaction type.
3. Bring compliance requirements into the design brief, not the QA review.
4. Test authentication, consent, and accessibility flows with real users before launch.
5. Audit location and payment flows against the regulatory checklist at each major build milestone.

Conclusion

Legal compliance in automotive apps is a set of constraints that determine what the product can do, how it must ask for data, when it can request attention from the driver, and how it must handle identity and money. The teams that treat these constraints as design inputs from day one build products that are both legally sound and better to use. The teams that discover them during QA or after an app store rejection spend the rest of the project paying for that delay.

The BMW accident reporting redesign is a useful endpoint to return to here. The compliance requirement, collecting sufficient evidence for an insurance claim while the driver was in a distressed post-accident state, was non-negotiable. The accelerometer trigger, the exploded car diagram, the voice recording for witness statements, all of those were design responses to a legal obligation. The compliance did not constrain the design. It directed it somewhere better than the original interface had reached on its own.

That is the relationship worth building between legal requirements and product design in automotive apps. Compliance tells you what must happen. Good design determines how it happens in a way that works for the person in the car.

If you are building or redesigning an automotive app and want to work through the compliance requirements before they shape themselves into rework, let's talk about your project.

Frequently Asked Questions