Achieve EU Data Act readiness with ease

As we enter 2026, the EU Data Act (Regulation (EU) 2023/2854), which is now in force across the entire European Union, is mandatory for all "connected" home appliance manufacturers. It has been applicable since 12 September 2025.

Compared to other industries, like automotive or agriculture, the situation is far more complicated. The implementation of connected services varies between manufacturers, and lack of connectivity is not often considered an important factor, especially for lower-segment devices.

The core approaches to connectivity in home appliances are:

• Devices connected to a Wi-Fi network and constantly sharing data with the cloud.
• Devices that can be connected via Bluetooth and a mobile app (these devices technically expose a local API that should be accessible to the owner).
• Devices with no connectivity available to the customer (no mobile app), but still collecting data for diagnostic and repair purposes, accessible through an undocumented service interface.
• Devices with no data collection at all (not even diagnostic data).

Apart from the last bullet point, all of the mentioned approaches to building smart home appliances require EU Data Act compliance, and such devices are considered "connected products", even without actual internet connectivity.

The rule of thumb is: if there is data collected by the home appliance or a mobile app associated with its functions, it falls under the EU Data Act.

Short overview of the EU Data Act

To make the discussion more concrete, it helps to name the key roles and the types of data upfront. Under EU Data Act, the user is the person or entity entitled to access and share the data; the data holder is typically the manufacturer and/or provider of the related service (mobile app, cloud platform); and a data recipient is the third party selected by the user to receive the data. In home appliances, “data” usually means both product data (device signals, status, events) and related-service data (app/cloud configuration, diagnostics, alerts, usage history, metadata), and access often needs to cover both historical and near-real-time datasets.

Another important dimension is balancing data access with trade secrets, security, and abuse prevention. Home appliances are not read-only devices. Many can be controlled remotely, and exposing interfaces too broadly can create safety and cybersecurity risks, so strong authentication and fine-grained authorization are essential. On top of that, direct access must be robust: rate limiting, anti-scraping protections, and audit logs help prevent misuse. Direct access should be self-service, but not unrestricted.

Current market situation

As of January 2026, most home appliance manufacturers (over 85% of the 40 manufacturers researched, responsible for 165 home appliance brands currently present on the European market) either provide data access through a manual process (ticket, contact form, email, chatbot) or do not recognize the need to share data with the owner at all.

If we look at the market from the perspective of how manufacturers treat the requirements the EU Data Act imposes on them, we can see that only 12.5% of the 40 companies researched (which means 5 manufacturers) provide full data access with a portal allowing users to easily access their data in a self-service manner (green on the chart below). 55% of the companies researched (yellow on the diagram below) recognize the need to share data with their customers, but only as a manual service request or email, not in an automated or direct way.

‍

‍

The red group (32.5%) consists of manufacturers who, according to our research:

• do not provide an easy way to access your data,
• do not recognize EU Data Act legislation at all,
• recognize the EDA, but their interpretation is that they don’t need to share data with device owners.

A contact form or email can be treated as a temporary solution, but it fails to fulfill the additional requirements regarding direct data access. Although direct access can be understood differently and fulfilled in various ways, a manual request requiring manufacturer permission and interaction is generally not considered "direct". (Notably, "access by design" expectations intensify for products placed on the market from September 2026.)

API access

We can't talk about EU Data Act implementation without understanding the current technical landscape. For the home appliance industry, especially high-end devices, the competitive edge is smart features and smart home integration support. That's why many manufacturers already have cloud API access to their devices.

Major manufacturers, like Samsung, LG, and Bosch, allow users to access appliance data (such as electric ovens, air conditioning systems, humidifiers, or dishwashers) and control their functions. This API is then used by mobile apps (which are related services in terms of the EU Data Act) or by owners integrating with popular smart home systems.

There are two approaches: either the device itself provides a local API through a server running on it (very rare), or the API is provided in the manufacturer's cloud (most common), making access easier from the outside world, securely through their authentication mechanism, but requiring data storage in the cloud.

Both approaches, in light of the EDA, can be treated as direct access. The access does not require specific permission from the manufacturer, anyone can configure it, and if all functions and data are available, this might be considered a compliant solution.

Is API access enough?

The unfortunate part is that it rarely is, and for more than one reason. Let's go through all of them to understand why Samsung, which has a great SmartThings ecosystem, still developed a separate EU Data Act portal for data access.

1. The APIs do not make all data accessible

The APIs are mostly developed for smart home and integration purposes, not with the goal of sharing all the data collected by the appliance or by the related service (mobile app).

Adding endpoints for every single data point, especially for metadata, will be costly and not really useful for either customers or the manufacturer. It's easier and better to provide all supplementary data as a single package.

2. The APIs were developed with the device owner in mind

The EU Data Act streamlines data access for all data market participants - not only device owners, but also other businesses in B2B scenarios. Sharing data with other business entities under fair, reasonable, and non-discriminatory terms is the core of the EDA.

This means that there must be a way to share data with the company selected by the device owner in a simple and secure way. This effectively means that the sharing must be coordinated by the manufacturer, or at least the device should be designed in a way that allows for secure data sharing, which in most cases requires a separate B2B account or API.

3. The APIs lack consent management capabilities

B2B data access scenarios require a carefully designed consent management system to make sure the owner has full control regarding the scope of data sharing, the way it's shared, and with whom. The owner can also revoke data sharing permission at any time.

This functionality falls under the scope of a partner portal, not a smart home API. Some global manufacturers already have partner portals that can be used for this purpose, but an API alone is not enough.

If an API is not enough - what is?

The EU Data Act challenge is not really about expanding the API with new endpoints. The recommended approach, as taken by the previously mentioned Samsung, is to create a separate portal solving compliance problems. Let's also briefly look at potential solutions for direct access to data:

• Self-service export - download package, machine-readable + human-readable, as long as the export is fast, automatic, and allows users to access the data without undue delay.‍
• Delegated access to a third party - OAuth-style authorization, scoped consent, logs.

• Continuous data feed - webhook/stream for authorized recipients.

These are the approaches OEMs currently take to solve the problem.

Other challenges specific to the home appliance market

Home appliance connectivity is different from the automotive market. Because devices are bound to Wi-Fi or Bluetooth networks, or in rare cases smart home protocols (ZigBee, Z-Wave, Matter), they do not move or change owners that often.

Device ownership change happens only when the whole residence changes owners, which is either the specific situation of businesses like Airbnb, or current owners moving out - which very often means the Wi-Fi and/or ISP (Internet Service Provider) is changed anyway.

On the other hand, it is hard to point to the specific "device owner". If there is more than one resident - effectively any scenario outside of a single-person household - there is no way to effectively separate the data applicable to specific individuals. Of course, every reasonable system would include a checkbox or notification stating that data can only be requested when there is a legal basis under the GDPR, but selecting the correct user or admin to authorize data sharing is challenging.

From a business perspective, a challenge also arises from the fact that there are white-label OEMs manufacturing for global brands in specific market segments. A good example here is the TV market - to access system data, there can be a Google/Android access point, while diagnostic data is separate and should be provided by the manufacturer (which may or may not be the brand selling the device). If you purchase a TV branded by Toshiba, Sharp, or Hitachi, it can all be manufactured by Vestel. At the same time, other home appliances with the same brand can be manufactured elsewhere. Gathering all the data and helping users understand where their data is can be tricky, to say the least.

Another important challenge is the broad spectrum of devices with different functions and collecting different signals. This requires complex data catalogs, potentially integrating different data sources and different data formats. Users often purchase multiple different devices from the same brand and request access to all data at once. The user shouldn't have to guess whether the brand, OEM, or platform provider holds specific datasets - the compliance experience must reconcile identities and data sources to make it easy to use.

Conclusion

Navigating the EU Data Act is complicated, no matter which industry we focus on. When we were researching the home appliance market, we saw very different approaches—from a state-of-the-art system created by Samsung, compliant with all EDA requirements, to manufacturers who explain in the user manual that to "access the data" you need to open system settings and reset the device to factory settings, effectively removing the data instead of sharing it. The market as a whole is clearly not ready.

Making your company compliant with the EU Data Act is not that difficult. The overall idea and approach is similar regardless of the industry you represent, but building or procuring a new system to fulfill all requirements is a must for most manufacturers.

For manufacturers seeking a faster path to compliance, Grape Up designed and developed Databoostr, the EU Data Act compliance platform that can be either installed on customer infrastructure or integrated as a SaaS system. This is the quickest and most cost-effective way to become compliant, especially considering the shrinking timeline, while also enabling data monetization.

The European Commission issued definitive guidance in September 2025 clarifying which vehicle data automotive manufacturers must share under the EU Data Act.

With enforcement beginning September 2026, OEMs must provide access to raw and pre-processed vehicle data while protecting proprietary algorithms. Direct user access is free, but B2B data sharing can be monetized under reasonable compensation rules.

As the September 2026 deadline nears, the European Commission has issued comprehensive guidance that clarifies exactly which vehicle data must be shared and how. For automotive manufacturers still planning their compliance strategy, it’s now essential to understand these details.

Why this guidance matters for automotive OEMs?

EU Data Act becomes enforceable in September 2026, requiring all connected vehicle manufacturers to provide direct data access to end users and their chosen third parties. While the regulation itself established the legal framework, the Commission's guidance document - published September 12, 2025 - provides automotive specific interpretation that removes much of the ambiguity manufacturers have faced.

This is no longer just a paper exercise. If you fall short, expect:

•  Heavy financial consequences
•  Serious business risk and reputational damage
•  Potential legal exposure across EU markets
•  A competitive disadvantage as compliant competitors gain market access

For OEMs without appropriate technological infrastructure or clear understanding of these requirements, the deadline is rapidly approaching.

At Grape Up, our expert team and  Databoostr platform have already helped multiple OEMs achieve compliance before the September deadline.  Learn more about our solution .

What vehicle data must be shared?

The September 2025 guidance establishes clear boundaries between data that falls within and outside the Data Act's scope, resolving one of the most contested issues in implementation planning.

In-scope data: Raw and pre-processed vehicle data

Manufacturers must provide access to data that characterizes vehicle operation or status. The guidance defines two categories that must be shared:

 Raw Data Examples:

•  Sensor signals: wheel speed, tire pressure, brake pressure, yaw rate
•  Position signals: windows, throttle, steering wheel angle
•  Engine metrics: RPM, oxygen sensor readings, mass airflow
•  Raw image/point cloud data from cameras and LiDAR
•  CAN bus messages
•  Manual command results: wiper on/off, air conditioning usage; component status: door locked/unlocked, handbrake engaged

 Pre-Processed Data Examples:

•  Temperature measurements (oil, coolant, engine, battery cells, outside air)
•  Vehicle speed and acceleration
•  Liquid levels (fuel, oil, brake fluid, windshield wiper fluid)
•  GNSS-based location data
•  Odometer readings
•  Fuel/energy consumption rates
•  Battery charge level
•  Normalized tire pressure
•  Brake pad wear percentage
•  Time or distance to next service
•  System status indicators (engine running, battery charging status) and malfunction codes and warning indicators

 Bottom line is this: If the data describes real-world events or conditions captured by vehicle sensors or systems, it's in scope - even when normalized, reformatted, filtered, calibrated, or otherwise refined for use.

The guidance clarifies that basic mathematical operations don't exempt data from sharing requirements. Calculating current fuel consumption from fuel flow rate and vehicle speed still produces in-scope data that must be accessible.

Out-of-scope data: Inferred and derived information

Data excluded from mandatory sharing requirements represents entirely new insights created through complex, proprietary algorithms:

•  Dynamic route optimization and planning algorithms
•  Advanced driver-assistance systems outputs (object detection, trajectory predictions, risk assessment)
•  Engine control algorithms optimizing performance and emissions
•  Driver behavior analysis and eco-scores
•  Crash severity analysis
•  Predictive maintenance calculations using machine learning models

 The main difference is this: The guidance emphasizes that exclusion isn't about technical complexity alone - it's about whether the data represents new information beyond describing vehicle status. Predictions of future events typically fall out of scope due to their inherent uncertainty and the proprietary algorithms required to generate them.

However, if predicted data relates to information that would otherwise be in-scope, and less sophisticated alternatives are readily available, those alternatives must be shared. For example, if a complex machine learning model predicts fuel levels, but a simpler physical fuel sensor provides similar data, the physical sensor data must be accessible.

How must data access be provided?

The Data Act takes a technology-neutral approach as of September 2025, allowing manufacturers to choose how they provide data access - whether through remote backend solutions, onboard access, or data intermediation services. However, three essential requirements apply:

1. Quality equivalence requirement

Data provided to users and third parties must match the quality available to the manufacturer itself. This means:

•  Equivalent accuracy - same precision and correctness
•  Equivalent completeness - no missing data points
•  Equivalent reliability - same uptime and availability
•  Equivalent relevance - contextually useful data
•  Equivalent timeliness - real-time or near-real-time as per manufacturer's own access

The guidance clearly prohibits discrimination: data cannot be made available to independent service providers at lower quality than what manufacturers provide to their own subsidiaries, authorized dealers, or partners.

2. Ease of access requirement

The "easily available" mandate means manufacturers cannot impose:

•  Undue technical barriers requiring specialized knowledge
•  Prohibitive costs for end-user access
•  Complex procedural hurdles

 In practice: If data access requires specialized tools like proprietary OBD-II readers, manufacturers must either provide these tools at no additional cost with the vehicle or implement alternative access methods such as remote backend servers.

3. Readily available data obligation

The guidance clarifies that “readily available data” includes:

•  Data manufacturers currently collect and store
•  Data they “can lawfully obtain without disproportionate effort beyond a simple operation”

For OEMs implementing extended vehicle concepts where data flows to backend servers, this has significant implications. Even if certain data points aren’t currently transmitted due to bandwidth limitations, cost considerations, or perceived lack of business use-case, they may still fall within scope if retrievable through simple operations.

When assessing whether obtaining data requires “disproportionate effort,” manufacturers should consider:

•  Technical complexity of data retrieval
•  Cost of implementation
•  Existing vehicle architecture capabilities

What are vehicle-related services under the Data Act?

The September 2025 guidance distinguishes between services requiring Data Act compliance and those that don’t.

Services requiring compliance (vehicle-related services)

Vehicle-related services require bi-directional data exchange affecting vehicle operation:

•     Remote vehicle control:    door locking/unlocking, engine start/stop, climate pre-conditioning, charging management
•     Predictive maintenance:    services displaying alerts on vehicle dashboards based on driver behavior analysis
•     Cloud-based preferences:    storing and applying driver settings (seat position, infotainment, temperature)
•     Dynamic route optimization:    using real-time vehicle data (battery level, fuel, tire pressure) to suggest routes and charging/gas stations

Services NOT requiring compliance

Traditional aftermarket services generally aren't considered related services:

•  Auxiliary consulting and analytics services
•  Financial and insurance services analyzing historical data
•  Regular offline repair and maintenance (brake replacement, oil changes)
•  Services that don't transmit commands back to the vehicle

 The key distinction: services must affect vehicle functioning and involve transmitting data or commands to the vehicle to qualify as "vehicle-related services" under the Data Act.

Understanding the cost framework for data sharing

The guidance issued in September 2025 draws a clear line in the Data Act's cost structure that directly impacts business models.

Free access for end users

When vehicle owners or lessees request their own vehicle data - either directly or through third parties they've authorized - this access must be provided:

•  Easily and without prohibitive costs
•  Without requiring expensive specialized equipment through user-friendly interfaces or methods

Paid access for B2B partners

Under Article 9 of the Data Act, manufacturers can charge reasonable compensation for B2B data access. This applies when business partners request data, including:

•  Fleet management companies
•  Insurance providers
•  Independent service providers
•  Car rental and leasing companies
•  Other commercial third parties

 For context: The Commission plans to issue detailed guidelines on calculating reasonable compensation under Article 9(5), which will provide specific methodologies for determining fair pricing. This forthcoming guidance will be crucial for manufacturers developing their data plans to monetize data while ensuring compliance.

 Key Limitation: These compensation rights have no bearing on other existing regulations governing automotive data access, including technical information necessary for roadworthiness testing. The Data Act's compensation framework applies specifically to the new data sharing obligations it creates.

Practical implementation considerations for September 2026

Backend architecture and extended vehicle obligations

The extended vehicle concept, where data continuously flows from vehicles to manufacturer backend servers, creates both opportunities and obligations. This architecture makes data readily available to OEMs, who must then provide equivalent access to users and third parties.

Action items:

•  Audit which data points your current architecture makes readily available
•  Ensure access mechanisms can deliver this data with equivalent quality to all authorized recipients
•  Evaluate whether data points not currently collected could be obtained "without disproportionate effort"

Edge processing and data retrievability

Data processed "on the edge" within the vehicle and immediately deleted isn't subject to sharing requirements. However, the September 2025 guidance encourages manufacturers to consider the importance of certain data points for independent aftermarket services when deciding whether to design these data points as retrievable.

Critical data points for aftermarket services:

•  Accelerometer readings
•  Vehicle speed
•  GNSS location
•  Odometer values

Making these retrievable benefits the broader automotive ecosystem and may provide competitive advantages in partnerships.

Technology choices and flexibility

While the Data Act is technology-neutral, chosen access methods must meet quality requirements. If a particular implementation - such as requiring users to physically connect devices to OBD-II ports - results in data that is less accurate, complete, or timely than backend server access, it fails to meet the quality obligation.

Manufacturers should evaluate access methods based on:

•  Data quality delivered to recipients
•  Ease of use for different user types
•  Cost-effectiveness of implementation
•  Scalability for B2B partnerships
•  Integration with existing digital infrastructure

Databoostr: Purpose-built for EU Data Act compliance

Grape Up's Databoostr platform was developed specifically to address the complex requirements of the EU Data Act. The solution combines specialized legal, process, and technological consulting with a proprietary data sharing platform designed for automotive data compliance.

 Learn more about Databoostr and how it can help your organization meet EU Data Act requirements.

Addressing the EU Data Act requirements

Databoostr's architecture directly addresses the key requirements established in the Commission's guidance:

 Quality Equivalence: The platform ensures data shared with end users and third parties matches the quality available to manufacturers, with built-in controls preventing discriminatory access patterns.

 Ease of Access: Multiple access methods—including remote backend integration and user-friendly interfaces - eliminate technical barriers for end users while supporting sophisticated B2B integrations.

 Readily Available Data Management : The platform handles both currently collected data and newly accessible data points, managing the complexity of determining what constitutes "readily available" under the guidance.

 Check our case studies :  EU Data Act Connected Vehicle Portal and  Connected Products Data Sharing Platform

Modular architecture for compliance and monetization

Databoostr's modular design addresses both immediate compliance needs and strategic opportunities. Organizations implementing the platform for EU Data Act requirements can seamlessly activate additional modules for data monetization:

•  Data catalog management for showcasing available data products
•  Subscription and package sales for B2B partners
•  Automatic usage calculation tracking data sharing volumes
•  Billing infrastructure supporting the Article 9 reasonable compensation framework

This setup supports both compliance and revenue growth from a single platform, reducing IT complexity while meeting the guidance's technical requirements.

Comprehensive implementation methodology

The Databoostr implementation approach aligns with the guidance's requirements through:

 Legal Consulting

•  Analyzing regulatory requirements specific to your vehicle types
•  Translating Data Act provisions into specific organizational obligations
•  Interpreting the September 2025 guidance within your business context
•  Creating individual implementation roadmaps

 Process Consulting

•  Designing compliant data sharing workflows for end users and B2B partners
•  Determining which data points fall in-scope based on your architecture
•  Establishing quality equivalence controls
•  Planning for reasonable compensation structures

 Technical Consulting

•  Pre-implementation analysis of existing data infrastructure
•  Solution architecture tailored to your extended vehicle implementation
•  Integration planning with backend systems
•  Addressing readily available data retrieval requirements

 Platform Customization

•  Integration with existing digital ecosystems
•  Custom components for specific vehicle architectures
•  Access method implementation (backend, onboard, or hybrid)
•  Quality assurance mechanisms

 Comprehensive Testing

•  Quality equivalence validation
•  Integration verification with existing IT infrastructure
•  Security testing ensuring compliant data sharing
•  Functional testing confirming alignment with guidance requirements

Post-implementation support

With the extended vehicle concept creating readily available data obligations, manufacturers need ongoing platform management. Databoostr provides:

•  Continuous monitoring of platform operation
•  Response to technical or functional issues
•  Supervision of ongoing compliance with Data Act requirements
•  Platform updates reflecting evolving regulatory interpretations

Timeline: What automotive OEMs should do now

 Now - March 2026: Complete data inventory, classify according to guidance definitions, design technical architecture, begin platform implementation

 March - July 2026: Finalize platform integration, conduct comprehensive testing, establish B2B partnership frameworks, train internal teams

 July - September 2026: Run parallel systems, validate compliance, prepare documentation for regulatory authorities, establish monitoring processes

 September 2026 and Beyond: Full enforcement begins, ongoing compliance monitoring, response to Commission's forthcoming compensation calculation guidelines

The path forward: Clear requirements, fixed deadline

The Commission's September 2025 guidance removes ambiguity that has delayed planning for some organizations. With regulatory requirements now precisely defined and less than eleven months until enforcement begins, manufacturers should be finalizing their compliance plans and beginning implementation.

The guidance encourages affected industry stakeholders to engage in dialogue achieving balanced implementation. The Commission also emphasizes coordination between Data Act enforcement authorities and other automotive regulators, including those overseeing type approval and data protection, to ensure smooth interplay between regulations.

For automotive manufacturers, three facts are now clear:

1.     The requirements are defined:    The September 2025 guidance specifies exactly which data must be shared, at what quality level, and through what access methods
2.     The deadline is fixed:    September 2026 enforcement is approaching rapidly
3.     The consequences are significant:    Non-compliance risks financial penalties, business disruption, and competitive disadvantage

Organizations that haven't yet begun implementation should treat the Commission's guidance as a final call to action.

Right To Repair and EU Data Act as a step towards data monetization.

Legislators try to shape the future

In recent years the automotive market has witnessed a growing amount of laws and regulations protecting customers across various markets. At the forefront of such legislation is the European Union, where the most significant disruption for modern software-defined vehicles come from the EU Data Act and EU AI Act. The legislation aims to control the use of AI and to make sure that the equipment/vehicle owner is also the owner of the data generated by using the device. The vehicle owner can decide to share the data with any 3rd party he wants, effectively opening the data market for repair shops, custom applications, usage-based insurance or fleet management.

Across the Atlantic, in the United States, there is a strong movement called “Right to Repair”, which effectively tries to open the market of 3rd party repair of all customer devices and appliances. This also includes access to the data generated by the vehicle. While the federal legislation is not there, there are two states that that stand out in terms of their approach to Right to Repair in the automotive industry – Massachusetts and Maine.

Both states have a very different approach, with Maine leaning towards an independent entity and platform for sharing information (which as of now does not exist) and Massachusets towards OEMs creating their own platforms. With numerous active litigations, including lawsuits OEMs vs State, it’s hard to judge what will be the final enforceable version of the legislation.

The current situation

Both pieces of legislation impose a penalty when it’s not fulfilled – severe in the case of EDA (while not final, the fines are expected to be substantial, potentially reaching up to €20 million or 4% of total worldwide annual turnover!), and slightly lower for state Right to Repair (for civil law suits it may be around $1000 per VIN per day, or in Massachusets $10.000 per violation).

The approach taken by the OEMs to tackle this fact varies greatly. In the EU most of the OEMs either reused existing software or build/procured new systems to fulfill the new regulation. In the USA, because of the smaller impact, there are two approaches: Subaru and Kia in 2022 decided to just disable their connected services (Starlink and Kia Connect respectively) in states with strict legislation. Others decided to either take part in litigation, or just ignore the law and wait. Lately federal judges decided in favor of the state, making the situation of OEMs even harder.

Data is a crucial asset in today’s world

Digital services, telematics, and in general data are extremely important assets. This has been true for years in e-commerce, where we have seen years of tracking, cookies and other means to identify customers behavior. The same applies to telemetry data from the vehicle. Telemetry data is used to repair vehicles, to design better features and services offering for existing and new models, identify market trends, support upselling, lay out and optimize charging network, train AI models, and more. The list never ends.

Data is collected everywhere. And in a lot of cases stored everywhere. The sales department has its own CRM, telemetry data is stored in a data lake, the mobile app has its own database. Data is siloed and dispersed, making it difficult to locate and use effectively.

Data platform importance

To solve the problem with both mentioned legislations you need a data sharing platform. The platform is required to manage the data owner consent, enable collection of data in single place and sharing with either data owner, or 3rd party. While allowing to be compliant with upcoming legislation, it also helps with identifying the location of different data points, describing it and making available in single place – allowing to have a better use of existing datasets.

A data platform like Grape Up Databoostr helps you quickly become compliant, while our experienced team can help you find, analyze, prepare and integrate various data sources into the systems, and at the same time navigate the legal and business requirements of the system.

Cost of becoming compliant

Building a data streaming platform comes at the cost. Although not terribly expensive, platform requires investment which does not immediately seem useful from a business perspective. Let’s then now explore the possibilities of recouping the investment.

• You can use the same data sharing platform to sell the data, even reusing the mechanism used to get user consent for sharing the data. For B2B use cases, the mechanism is not required.
• Legislation mainly mandates to share data “as is”, which means raw, unprocessed data. Any derived data, like predictive maintenance calculation from AI algorithms, proprietary incident detection systems, or any data that is processed by OEM. This allows not just to put a price tag on data point, but also to charge more due to additional work required to build analytics models.
• You can share the anonymized datasets, which then can be used to train AI models, identify EVs charging patterns, or plan marketing campaigns.
• And lastly, EU Data Act allows to charge fair amount for sharing the data, to recoup the cost of building and maintaining the platform. The allowed price depends on the requestor, where enterprises can be charged with a margin, and the data owner should be able to get data for free.

We can see that there are numerous ways to recoup the cost of building the platform. This is especially important as the platform might be required to fulfill certain regulations, and procuring the system is required, not optional.

The power of scale in data monetization

As we now know, building a data streaming platform is more of a necessity, than an option, but there is a way to change the problem into an opportunity. Let’s see if the opportunity is worth the struggle.

We can begin with dividing the data into two types – raw and derived. And let’s put a price tag on both to make the calculation easier. To further make our case easier to calculate and visualize, I went to high-mobility and checked current pricing for various brands, and took the average of lower prices.

The raw data in our example will be $3 per VIN per month, and derived data will be $5 per VIN per month. In reality the prices can be higher and associated with selected data package (the data from powertrain will be different from chassis data).

Now let’s assume we start the first year with a very small fleet, like the one purchased for sales representatives by two or three enterprises – 30k of vehicles. Next year we will add a leasing company which will increase the number to 80k of vehicles, and in 5 years we will have 200k VINs/month with subscription.

Of course, this represents just a conservative projection, which assumes rather small usage of the system and slow growth, and exclusive subscription to VIN (in reality the same VIN data can be shared to an insurance company, leasing company, and rental company).

This is constant additional revenue stream, which can be created along the way of fulfilling the data privacy and sharing regulations.

Factors influencing the value

$3 per VIN per month may initially appear modest. Of course with the effect of scale we have seen before, it becomes significant, but what are the factors which influence the price tag you can put on your data?

• Data quality and veracity – the better quality of data you have, the less data engineering is required on the customer side to integrate it into their systems.
• Data availability (real-time versus historical datasets) – in most cases real-time data will be more valuable – especially when the location of the vehicle is important.
• Data variety – more variety of data can be a factor influencing the value, but more importantly is to have the core data (like location and lock state). Missing core data will reduce the value greatly.
• Legality and ethics – the data can only be made available with the owner consent. That’s why consent management systems like the ones required by EDA are important.

What is required

To monetize the data you need a platform, like Grape Up’s Databoostr. This platform should be integrated into various data sources in the company, making sure that data is streamed in a close to real-time way. This aspect is important, as quite a lot of modern use cases (like Fleet Management System) requires data to be fresh.

Next step is to create pricing strategy and identify customers, who are willing to pay for the data. It is a good start to ask the business development department if there are customers who already asked for data access, or even required to have this feature before they invest in bigger fleet.

The final step would be to identify the opportunities to further increase revenue, by adding additional data points for which customers are willing to pay extra.

Summary

Ultimately, data is no longer a byproduct of connected vehicles – it is a strategic asset. By adopting platforms like Grape Up’s Databoostr, OEMs can not only meet regulatory requirements but also position themselves to capitalize on the growing market for automotive data. With the right strategy, what begins as a compliance necessity can evolve into a long-term competitive advantage.

‍