DEV Community: Order Group

AMLR 2027 and KYC in Lending Apps: How Remote Onboarding Changes Before 10 July 2027

Filip Szamborski — Wed, 28 Oct 2026 01:05:13 +0000

The AMLR is Regulation (EU) 2024/1624 on preventing money laundering and terrorist financing, applied directly across the EU without a national act. It applies from 10 July 2027 and covers lenders, so it also reaches lending apps, including their remote onboarding.

On 1 October 2026 AMLA, the EU Anti-Money Laundering Authority, sent the Commission its final report with draft technical standards on customer due diligence, and from 10 July 2027 the AMLR applies to consumer lenders in the EU. The standards are not in force yet, and the technical details of remote identity verification in a lending app wait for the Commission to adopt them. This article reads the AMLR from the product side and is not legal advice. Which rules apply to you depends on your company's status, so confirm it with your lawyer. For the terms themselves, see the glossary entries on the AMLR and KYC.

What is the AMLR and does it apply to lenders?

The AMLR is a regulation, so it applies as written in every member state from 10 July 2027 (Article 90). A later date, 10 July 2029, applies only to the entities named in Article 3(3)(n) and (o). Lenders fall under the main date.

Two companion acts complete the EU anti-money laundering package. Directive (EU) 2024/1640 (AMLD6) must be transposed by 10 July 2027. Regulation (EU) 2024/1620 sets up the authority AMLA, which writes the technical standards that fill in the AMLR.

Under Article 2(6), a financial institution includes a creditor within the meaning of Directive 2008/48/EC (consumer credit) and Directive 2014/17/EU (mortgage credit), and financial institutions are obliged entities, the companies that have to apply the rules. Credit intermediaries can be covered too, when their activity exposes them to money laundering risk. When an intermediary acts on behalf of a lender, recital 22 places the requirements on the lender. The details differ for a lending institution, a bank and an intermediary.

When does the AMLR apply, and what is still missing?

The date of application is fixed, but the technical standards for remote verification are not final. The status below is as of October 2026 and changes quickly.

10 July 2027: the AMLR applies (Article 90) and the transposition deadline for AMLD6 runs out.
9 February to 8 May 2026: AMLA consulted on the draft regulatory technical standards (RTS) on customer due diligence (CDD) under Article 28(1) of the AMLR.
1 October 2026: AMLA published the final report with the draft RTS (the document is dated 30 September 2026) and sent it to the European Commission for adoption. The standards become binding only after the Commission adopts them and they are published in the Official Journal of the EU.
After adoption: under the draft, the RTS enter into force on the 20th day after publication and apply six months later.

The draft covers the requirements and information for standard, simplified and enhanced due diligence, the reliable and independent sources for verifying identity, and the attributes of electronic identification means and qualified trust services.

The final report keeps the check of the authenticity of identity documents. Recital 8 requires checking that the document is authentic, including that it has not been forged or altered. Article 6(1)(d) requires security features in the document that confirm its authenticity.

It also leaves room in sanctions screening. Lists may be checked with automated tools, manual checks or a combination of both, depending on the nature, risk and size of the entity (Article 25(2)(a)).

For the team, this means the date is known, while the technical details of remote verification wait for the Commission. Keep the order of verification methods and the risk rules in backend configuration, so a change after the Commission's decision is a configuration change and not a rebuild.

How does the AMLR change remote identity verification?

The AMLR names two ways to verify a customer's identity, and the draft RTS add a fallback for people who cannot use either. Under Article 22(6), identity is verified in one of two ways:

On the basis of a document: an identity document, passport or equivalent, where relevant with information from reliable and independent sources.
With electronic identification: electronic identification means at assurance level "substantial" or "high" under Regulation (EU) No 910/2014 (eIDAS), together with relevant qualified trust services.

Recital 66 adds that obliged entities should accept electronic identification under eIDAS. Where it is not available, verification should rely on the relevant qualified trust services.

The draft RTS count an electronic identification means whether or not it was notified, as long as it meets level "substantial" or "high" under Implementing Regulation (EU) 2015/1502. That includes the European Digital Identity Wallets (EUDI Wallet). Poland has a notified electronic identification scheme at levels "substantial" and "high" (notified on 19 April 2023, OJ EU 2023/C 136/02), which is reported to include the Polish government trusted profile and the electronic ID card.

The fallback in Article 7 of the draft RTS

Article 7 of the draft RTS applies when a person cannot reasonably be expected to present a document in person and has no access to electronic identification or qualified trust services under Article 22(6)(b). The obliged entity then verifies identity on the basis of a document using alternative solutions that draw on reliable and independent sources. Five safeguards apply:

the person presenting the document is checked to be its holder;
the communication is protected for integrity and confidentiality;
image, video, sound and data come in a readable format and quality that allow the person to be identified without doubt;
the process stops when there is a technical fault, an unexpected interruption of the connection, or doubt about the identity or the integrity of the process;
the verified data and documents are valid and up to date, and copies are stored with a timestamp, securely and in a form that allows verification after the fact.

An entity that uses such a solution must be able to explain why the customer was not verified with the methods of Article 22(6), and to show the supervisor that the solution meets Article 7.

Article 7 describes the safeguards and names no specific technique, such as a selfie, liveness detection or video. According to the recitals of the draft, entities can keep using existing remote onboarding tools that meet these requirements. Article 27 adds a step for incomplete identity data: when an electronic identification means or a qualified trust service does not carry every attribute needed, the entity obtains and verifies the missing ones with other means that Article 22(6) allows. The minimum attributes are listed in Annex I.

Verification transfers and open banking

A verification transfer (a small payment that confirms the customer owns the account) and account data obtained through open banking are not listed among the methods of identity verification, in Article 22(6) of the AMLR or in Articles 6 and 7 of the draft RTS. In our reading, they work as supporting signals: they confirm the bank account and help against fraud, and the identity itself is verified with a document or electronic identification.

Polish lenders and the PESEL register

A Polish lender has one more duty next to AML. Under Article 9b of the Consumer Credit Act, in force since 1 June 2024, the lender checks in the register of restricted PESEL numbers (PESEL is the Polish national ID number) whether the borrower's number is restricted before it concludes the credit or loan agreement. It is a separate step from identity verification and has its own record.

KYC vs eKYC

KYC (know your customer) is the process of confirming a customer's identity at onboarding. eKYC is its digital, remote form. It usually combines a scan of the identity document with biometrics, such as comparing a selfie with the photo in the document, and screening against lists of politically exposed persons (PEP) and sanctions. eKYC is a method of performing KYC and leaves every legal duty in place.

What changes in a lending app's onboarding: a checklist for the CTO

A lending app's onboarding needs a hierarchy of verification methods set in the backend, a log of why the fallback was used, a way to stop and resume a session, a step for completing missing attributes, timestamped copies, and versioned risk rules. The checklist below is made of our engineering recommendations and has no legal force.

Verification routes under the AMLR and the draft RTS, and what the app must support

Route	Legal basis	What the app must support
Electronic identification, level substantial or high	AMLR Article 22(6)(b)	Integration with the eID scheme, a record of the assurance level
Qualified trust services	AMLR Article 22(6)(b)	Handling of the trust service result, a step that completes missing attributes (Article 27 of the draft RTS)
Document verified remotely, with safeguards (fallback)	Article 7 of the draft RTS	Check of the document holder, image quality, a stop on doubt, timestamped copies, a recorded reason for using the fallback

Answer each question with yes or no:

Does the app have a hierarchy of KYC methods (electronic identification first, a remote document check as the fallback) that is configured in the backend?
Does the system record why the fallback was used, meaning why electronic identification was unavailable? Article 7 of the draft RTS requires the entity to be able to justify it to the supervisor.
Does the remote verification stop on a fault, a dropped connection or a doubt, and can it be resumed without losing the application? (Article 7(d) of the draft RTS; see the AvaFin notes below.)
Is there a step that completes the attributes missing from an electronic identification means? (Article 27 of the draft RTS.)
Are copies of documents, images and recordings stored with a timestamp, and can they be reproduced for a check after the fact? (Article 7(e).)
Is the customer risk assessment stored as versioned rules, so you can say which version of a rule produced which result?
Is there an audit trail of which eKYC provider verified what, and when?
Do the verification transfer and the account data serve as fraud signals next to a separate identity verification method?
Can the team change the hierarchy of methods and the rules within days of the Commission adopting the RTS, without a new release in the App Store and Google Play?

KYC logic should also stay consistent with the creditworthiness assessment and human intervention under CCD2, which we cover in CCD2 for Lending Apps, and with the logs required by the AI Act, which we cover in EU AI Act and Credit Scoring.

What KYC flows in lending apps teach us

We build lending apps and integrate external verification services. The notes below come from Aasa24, and from AvaFin for the bank account verification and the order of the application steps. Three things stand out: a clear status for each stage, retries, and a way back into an interrupted process.

Aasa24 is a lending app with card features that we develop.

The online identity check for a card application runs on several levels: a KYC step with a scan of the identity document that the customer can repeat, PESEL with an SMS code, and a repeated or manual verification in difficult cases.
A customer rejected after three failed KYC attempts can start verification again on a new application.
KYC tasks are retried automatically, and the flag of a verified customer stays saved.
After the customer taps "Next" on a pending application, the app checks the status of the KYC verification. This was added in October 2025.
KYC is also part of the flow after the contract is signed.
After a positive bank account verification through open banking, the card application moves to a separate KYC status.
Releases ship every 3-4 weeks.

AvaFin is a lending app that we also build. The customer chooses one of two ways to verify the bank account: logging in to online banking, which gives the account history (Kontomatik), or a verification transfer (Autopay). The app monitors the status of the verification and handles a failure or a timeout without dropping the application. A central system sets the order of the application steps, so changing the order or the scope of the steps does not need a new app version.

The verification providers in both apps are external and belong to the clients. More of our work in this area is on the fintech software development and mobile app development pages.

FAQ

What is the AMLR?

The AMLR is Regulation (EU) 2024/1624 on preventing the use of the financial system for money laundering or terrorist financing. It applies directly in every EU member state from 10 July 2027, without a national act, and sets the customer due diligence rules for obliged entities, including consumer lenders.

When does the AMLR apply?

The AMLR applies from 10 July 2027. AMLA published the final report with the draft technical standards on customer due diligence on 1 October 2026 (the document is dated 30 September) and passed it to the European Commission. Once adopted, the standards apply six months after entry into force.

Does the AMLR apply to lenders and loan apps?

Yes. Under Article 2(6), creditors for consumer credit and mortgage credit are financial institutions, so they are obliged entities. The details depend on the company's status, for example a loan institution, a bank or an intermediary, so confirm yours with a lawyer.

What is the difference between KYC and eKYC?

KYC is the confirmation of a customer's identity at onboarding. eKYC is its digital, remote version, usually built from a scan of the identity document, biometrics such as a selfie comparison, and screening against PEP and sanctions lists. eKYC is a method of performing KYC and leaves every legal duty in place.

Is video identification still allowed under the AMLR?

The draft RTS, which the Commission has not adopted yet, allow remote verification of a document as a fallback when the customer has no access to electronic identification. Article 7 sets safeguards: checking that the person is the document holder, image and sound quality, stopping on doubt, and timestamped copies. It names no specific technique.

What is the AMLA RTS on customer due diligence?

The RTS are regulatory technical standards under Article 28(1) of the AMLR. They specify what information to collect at each level of due diligence and which sources and electronic identification means count for verifying identity. The final report dated 30 September 2026 now waits for adoption by the European Commission.

Is a verification transfer enough for KYC under the AMLR?

The identity verification methods in the AMLR and the draft RTS are a document, or electronic identification with qualified trust services. A verification transfer is not named among them, so we treat it as a supporting signal that confirms the account and helps against fraud. This is our reading of the texts.

What changes for KYC in a lending app?

A lending app needs a hierarchy of verification methods set in the backend, a log of why the fallback was used, a way to stop and resume a session, a step for completing missing attributes, timestamped copies, and versioned risk rules. The checklist above lists each of these.

How does the AMLR relate to CCD2 and the AI Act?

CCD2 regulates the credit process and consumer rights, and the AI Act covers credit scoring. The AMLR covers the identification and due diligence of the customer. In an app they meet in the application flow, so the three share data and logs. See our articles on CCD2 and the AI Act and credit scoring.

Originally published at ordergroup.co.

IoT Architecture: Layers, Diagram and How Industrial Systems Are Built

Filip Szamborski — Tue, 27 Oct 2026 01:13:05 +0000

An IoT architecture moves data from devices through connectivity, an edge gateway and a cloud platform to the application, and sends commands back the same way. This guide compares the 3-layer and 5-layer models and lists what to check so that a dropped connection does not go unnoticed in production.

An IoT architecture carries data through a chain of layers: devices and sensors, connectivity, an edge gateway, a cloud platform that ingests, processes and stores the data, and the application people work in. Commands travel back to the devices the same way. Textbooks compress this into three layers (perception, network, application) or five (perception, transport, processing, application, business).

Most guides draw the same boxes. The difference between a diagram and a production system shows up when the connection drops: an MQTT client with a clean session loses its subscriptions without any error, and an edge device that has gone offline can still look healthy in the portal. The examples come from industrial and energy systems we have built for Skyfri, Zeronest and KYOTO as part of our industrial IoT services.

IoT architecture layers: the 3-layer and 5-layer models

The two models you will meet most often have three layers and five. The three-layer model has a perception layer (the physical devices and sensors), a network layer (connectivity) and an application layer (the service delivered to the user). The five-layer model splits the network layer into transport and processing and adds a business layer on top, which manages the whole system and its business and profit models.

The study "Internet of Things Architectures: A Comparative Study" (dos Santos et al., 2020, arXiv 2004.12936) describes both models and notes that sources name the middle layers differently. The same study points out that the five-layer model leaves security and privacy out. That is why search results show anything from four to six layers. For the basic terms, see the IoT glossary entry and our explainer on what industrial IoT is.

When you build a system, it helps more to know what each layer does and how it fails. The table below uses the layers you actually deploy.

IoT architecture layers, what each does, a typical risk in production (with the source named where it comes from external documentation) and an example from our projects.

Layer	What it does	Typical risk in production	Example from our projects
Devices and sensors	Read values from equipment and accept commands	The data path depends on the manufacturer's cloud or the household Wi-Fi	Zeronest: device wired to the inverter over RS485/Modbus, reporting over LTE
Connectivity	Moves messages between device, gateway and platform	An MQTT client with a clean session loses its subscriptions after a disconnect (HiveMQ, ThingsBoard)	Zeronest: MQTT with TLS 1.2 to AWS IoT Core
Edge gateway	Runs local logic and buffers messages during outages	Buffered messages expire after the TTL (7200 s by default on Azure IoT Edge) or when the disk fills (Microsoft Learn)	Skyfri: EMS control decisions made locally on Azure IoT Edge, so the EMS could run fully offline
Cloud platform (ingestion, processing, storage)	Receives, processes and stores data for the whole fleet	On AWS IoT Core, a persistent session expires after one hour by default and QoS 2 is not supported (AWS docs)	Zeronest: AWS IoT Core; Skyfri: Azure IoT Hub as the cloud side
Application	Dashboards, alerts, reports and integrations	On Azure IoT Edge, a device that went offline can still show as healthy (200 OK) because the agent stops reporting (Microsoft Learn)	Skyfri: monitoring runs as a separate layer in Skyfri Intelligence

The application layer is where industrial IoT analytics and dashboard design come in.

What the extra layers in the 5-layer model change

In the three-layer model, "network" covers both moving the data and making sense of it. The five-layer model separates transport (getting messages from the device to the platform) from processing (storing, filtering and analysing them). In a real system those are often different services with different owners. The business layer adds questions of system management and profit that the three-layer model does not ask.

IoT architecture diagram: a reference industrial system

A reference IoT architecture diagram for an industrial system has two paths. Telemetry goes up from the device, and commands come back down.

Telemetry path, from device to application:

Device or sensor. Reads values from equipment, such as an inverter, a battery or a meter, often over a fieldbus such as RS485 with Modbus.
Edge gateway. Collects readings locally, runs logic that cannot wait for the cloud and buffers messages when the uplink is down.
Broker and ingestion. An MQTT broker or a managed service such as AWS IoT Core or Azure IoT Hub receives messages over a secure connection.
Processing and storage. Rules, stream processing and time-series storage turn raw readings into state and history.
Application. Dashboards, alerts, reports and integrations used by operators and the business.

Command path, from application to device: a setpoint or schedule leaves the application, passes through the platform and the broker, reaches the edge gateway and is written to the device. Most generic diagrams leave this path out, and it is the one with the strictest requirements, because a command that arrives late or twice can change how equipment behaves.

A real chain: Zeronest

In the Zeronest system, a device wired to the inverter over RS485/Modbus sent readings over LTE, using MQTT with TLS 1.2, to AWS IoT Core. The device, the Bzyk D200, is Zeronest's own hardware, and the LTE link kept the data path independent of the inverter manufacturer's cloud and of the household Wi-Fi. Customer data stayed in the EU. Every minute the system decided whether to charge, discharge or sell energy. It worked with [[f:zn-brands]] and ran on [f:zn-inst]. The Zeronest case study describes the platform built on this chain.

Edge or cloud: where should the logic run?

Run the logic that has to keep working without the internet at the edge, and send everything that benefits from fleet-wide data to the cloud. Control decisions for physical equipment usually belong at the edge. Analytics, reporting and comparisons across many sites belong in the cloud.

The energy management system (EMS) we built for Skyfri's solar and battery platform went into production in June 2024 at [[f:sk-plants]] and controlled [[f:sk-mwh]] of battery storage. The EMS made its control decisions locally on Azure IoT Edge, so it could run fully offline, with Azure IoT Hub as the cloud side. It worked with batteries and inverters from several manufacturers. Monitoring runs as a separate layer in Skyfri's own product, Skyfri Intelligence.

What offline really means on Azure IoT Edge

Microsoft's documentation, "Operate Azure IoT Edge devices offline" on Microsoft Learn, sets out the details:

After the first sync with IoT Hub, an edge device can work without a connection indefinitely.
The edge hub buffers outgoing messages and, when the connection returns, sends them in the original order.
How long messages survive depends on the time-to-live setting and free disk space. The default TTL is 7200 seconds, or two hours.
While offline, the agent does not report status, so the portal can keep showing the device as healthy (200 OK).

If an outage can last longer than the buffer TTL, raise it and size the disk, or accept that older readings will be lost. And do not treat a green status as proof that the device is online.

Which protocols connect the IoT architecture layers: MQTT, Modbus, OPC UA, HTTP?

Modbus links devices to the gateway, OPC UA carries data with its information model on the factory floor, MQTT moves messages from the gateway to the cloud, and HTTP serves polling and REST integrations. Each fits a different boundary between layers.

Protocols that connect the IoT architecture layers and where each fits.

Protocol	Model	Where it fits	Note
Modbus	Fieldbus protocol, often over RS485	Device to gateway	The register map (which value sits at which address) differs between manufacturers, so someone has to own those maps
OPC UA	Data with an information model	Factory floor, especially brownfield plants	In the VDMA 2025 study of German machinery and plant makers, 57% of companies used it in production and about half of new products already supported it
MQTT	Lightweight publish/subscribe	Gateway to cloud; devices with limited resources and unreliable networks	Three QoS levels: 0 (at most once), 1 (at least once), 2 (exactly once)
HTTP	Request/response	Polling and REST integrations	Less suited to a continuous stream of telemetry

The OPC UA figures come from the VDMA 2025 interoperability study of German machinery and plant makers, reported by fertigungstechnik.de on 28 November 2025. The MQTT quality-of-service levels are defined in the OASIS specification.

MQTT or OPC UA?

You often use both. In an OPC Foundation article, "OPC UA, MQTT and Information Interoperability", Erich Barnstedt, Chief Architect Standards & Consortia for Azure IoT at Microsoft, describes OPC UA as the payload and MQTT as the transport. OPC UA gives the data its meaning; MQTT moves it efficiently to the cloud.

Check the platform limits too. According to the AWS IoT Core Developer Guide, AWS IoT Core supports QoS 0 and 1 but not QoS 2. A persistent session stores subscriptions and unacknowledged QoS 1 messages. By default it expires after one hour. In MQTT 3 that is an account-wide setting; in MQTT 5 you can raise the limit to seven days. If your design depends on exactly-once delivery, it has to come from your own application logic, such as idempotent commands.

What breaks in production: an IoT architecture checklist for CTOs

Many production failures happen at the joins between layers, often when a connection drops. One industry pattern, described by HiveMQ in "MQTT Essentials part 7", by ThingsBoard in "Non-persistent and persistent sessions" and in the AWS IoT documentation, shows how this goes unnoticed:

An MQTT client that connects with a clean session loses its subscriptions when the connection drops and has to subscribe again after reconnecting.
With a persistent session (clean session set to false), the broker keeps the subscriptions and queues messages for the same client ID.
In MQTT 5, Clean Start and Session Expiry Interval replace the clean session flag. The expiry interval defaults to 0, so the session ends when the client disconnects.
The client should keep its own list of subscriptions and restore them after reconnecting, whatever the broker does.

A client that reconnects without resubscribing looks connected and receives nothing. Combine that with an edge status that stays green while offline, and a device can go quiet without anyone noticing.

Checklist: before you approve an IoT architecture

What works without the internet? List the functions that must keep running offline and confirm they run at the edge.
How much can the buffer hold? Check the message TTL and free disk space against the longest outage you expect.
Does the MQTT client resume the connection and its subscriptions? Use a persistent session or keep your own subscription list and restore it.
Does device status tell the truth when offline? Make sure a device that stopped reporting does not still show as healthy.
Who owns the Modbus register maps and the devices? Decide who maintains the maps for each manufacturer and model.
How do you update devices? Plan staged rollouts rather than updating the whole fleet at once.
Where does the data live? Confirm the regions, for example that customer data stays in the EU.
What depends on the manufacturer's cloud? Identify every function that stops if a vendor's cloud or the household Wi-Fi goes down.

For the security side of these decisions, see our guide to IoT security.

How to choose an IoT architecture before you build

Choose an IoT architecture by settling your constraints first: the devices and protocols on site, offline behaviour, response times, updates and security boundaries. Answer these questions before anyone draws a diagram:

Which devices and protocols are already on site, and which will be added?
What has to keep working during an outage, and for how long?
Which decisions need a response in seconds, and which can wait for the cloud?
How will devices be updated and replaced over the life of the system?
Where are the security boundaries between the device network, the platform and the users?

KYOTO shows how an architecture grows. Its MVP started as UX/UI work and, over three and a half years of work on industrial IoT and a digital twin of a thermal energy storage system, grew into a SCADA-based building management system (BMS) that monitors and controls energy flow in real time. More projects are in our industrial IoT examples.

Our work covers the software architecture of these systems. We do not write microcontroller firmware (C/C++), embedded Linux or Bluetooth Low Energy (BLE), and PCB design goes to a hardware partner.

To map this before anything is built, we run a free discovery workshop that covers hardware, protocols, offline behaviour, updates and security boundaries.

IoT architecture: frequently asked questions

What are the layers of IoT architecture?

The three-layer model has perception (devices and sensors), network (connectivity) and application (the service for the user). The five-layer model splits the network into transport and processing and adds a business layer. In a deployed system the layers are devices, connectivity, edge gateway, cloud platform and application.

What is the difference between 3-layer and 5-layer IoT architecture?

The five-layer model divides the three-layer network layer into transport, which moves messages, and processing, which stores and analyses them. It also adds a business layer for managing the system and its business and profit models. Sources name the middle layers differently, so counts of four to six layers are common.

Should IoT data be processed at the edge or in the cloud?

Process at the edge anything that must keep working without the internet, such as control of physical equipment. Send to the cloud whatever gains from fleet-wide data, such as analytics and reporting. The EMS we built for Skyfri made its control decisions locally on Azure IoT Edge, so it could run fully offline.

MQTT or OPC UA for industrial IoT?

Often both. OPC UA is common on the factory floor because it carries an information model with the data, while MQTT is a lightweight publish/subscribe transport to the cloud. Microsoft's Erich Barnstedt describes OPC UA as the payload and MQTT as the transport in an OPC Foundation article.

What happens to an IoT system when the internet connection drops?

Azure IoT Edge keeps working offline, buffers outgoing messages for up to 7200 seconds by default and, when the connection returns, sends them in the original order. An MQTT client with a clean session loses its subscriptions and must resubscribe. While offline, device status may still look healthy in the portal.

Next steps

If you are planning a connected system and want the layers, protocols and offline behaviour settled before development starts:

Originally published at ordergroup.co.

MCP vs API: What We Learned Running an MCP Server in Production

Filip Szamborski — Mon, 26 Oct 2026 03:11:04 +0000

How MCP differs from a classic API, when to use each, the attacks an MCP server faces and the server-side gates we run in production.

An API gives a programmer a fixed contract of endpoints, while MCP lets an AI agent ask a server which tools it offers and choose among them by their descriptions. Anthropic introduced the Model Context Protocol (MCP) on 25 November 2024 as "an open standard that enables developers to build secure, two-way connections between their data sources and AI-powered tools".

Since 9 July 2026 we have run a production MCP server for our own CMS, built on Wagtail. AI agents can call 164 tools on it, and no agent can publish a page whose brief a person has not approved.

How MCP works: host, client and server

MCP uses a client-host-server architecture. The host is the AI application the user works in. It creates and coordinates several clients and enforces security policies and user consent. Each client connects to exactly one server, and each server exposes capabilities to the model.

The protocol runs on JSON-RPC. A server can be a local process on the developer's machine or a remote service reached over the network. The specification dated 2026-07-28 describes MCP as stateless: every request carries its own protocol version and capabilities, with no session at the protocol level.

Tools, resources and prompts

A server offers three kinds of building blocks:

Tools are functions the model can call, such as "create a page" or "list case studies".
Resources are passive data the model can read, for example a log file or a database schema.
Prompts are ready-made templates for a type of interaction.

Capability negotiation and isolation

Client and server declare which features they support. In the 2026-07-28 specification the client attaches its capabilities to every request and the server announces its own in response to server/discover. Our public endpoint declares the earlier versions 2025-06-18, 2025-03-26 and 2024-11-05, so it does not use server/discover or stateless requests.

By design, a server should not see the whole conversation or look into other servers. The full history stays with the host, and a server only learns what the host passes to it.

Who maintains MCP

Since December 2025 MCP has belonged to the Agentic AI Foundation, hosted by the Linux Foundation, after Anthropic donated it; governance of the project did not change. Anthropic, Block and OpenAI co-founded the foundation, with support from Google, Microsoft, AWS, Cloudflare and Bloomberg, among others. The first adopters named in the November 2024 announcement were Block and Apollo, plus the developer tools Zed, Replit, Codeium and Sourcegraph. Anthropic's December 2025 announcement counted more than 10,000 active public MCP servers.

MCP vs API: the difference

A traditional API exposes fixed endpoints and assumes that the programmer knows in advance which operations to call. An MCP server publishes a list of tools, each with a name, a description and a typed input schema; the client asks what is available and passes those descriptions to the model, which picks the tool it needs. Comparisons such as Codecademy's "Model Context Protocol (MCP) vs. APIs: Architecture & Use Cases" and TrueFoundry's "MCP vs API" describe the difference the same way.

How a traditional API and an MCP server differ for the client that uses them.

Criterion	Traditional API	MCP server
Who discovers what is available	The programmer, from the documentation	The AI client, by asking the server for its tools
Contract	Fixed endpoints	A list of tools, resources and prompts
Description of operations	Written for people in the docs	Name, description and typed input schema read by the model
Main user	Application code written by a developer	An AI agent working inside a host application
Authentication and consent	Handled by the integrating application	The host enforces user consent and policies; the server can offer a public scope and a token-only scope
When the contract changes	The client code has to change	The client reads the updated tool list
Typical use	System-to-system integration	AI assistants and agents working with your system

Show all rows (7)Show fewer rows

MCP does not replace APIs. In many production systems the MCP server calls an existing API underneath, so the API marks the boundary of the service and MCP marks the boundary of the agent.

When to use MCP and when an API is enough

Use a plain API when a programmer writes the integration and knows the operations up front. That covers most system-to-system work with a stable contract.

MCP makes sense when an AI agent or assistant (ChatGPT, Claude, Cursor) will use your system and has to choose tools from their descriptions. It also helps when one server should serve many AI clients at once, because each client reads the same tool list instead of getting its own integration.

MCP is not tied to Claude. According to Anthropic's December 2025 announcement, ChatGPT, Cursor, Gemini, Microsoft Copilot and Visual Studio Code support it too.

MCP server security: what can go wrong

The main risks for an MCP server are confused deputy, token passthrough, server-side request forgery, state handle hijacking, compromise of a local server and unvalidated OAuth authorization URLs. Part of MCP security sits in the protocol itself. The host enforces user consent and policies, and a server sees neither the full conversation nor other servers. The rest depends on how you build and deploy the server.

The official MCP guide "Security Best Practices" (version 2026-07-28) describes the main attacks:

Confused deputy. A server with its own privileges acts on behalf of a client that should not have them, for example through a shared OAuth client.
Token passthrough. The server accepts a token that was not issued for it and forwards it to downstream services, which breaks audit and access control.
Server-side request forgery (SSRF). The server is tricked into requesting internal addresses it can reach and the attacker cannot.
State handle hijacking. An attacker reuses or guesses a handle that ties requests to an earlier interaction.
Local MCP server compromise. A server running on the user's machine is started or controlled by an untrusted party.
Unvalidated OAuth authorization URLs. A malicious server sends the client to an authorization address it should not trust.

The guide also covers stdio transport in setups with a proxy, several OAuth topics (mix-up attacks, localhost redirect impersonation, trust policies for Client ID Metadata Documents) and scope minimization. Scope minimization means asking for the minimal read scope first and raising permissions only when an operation needs them. The guide gives mitigations for each.

What we learned running an MCP server in production

On our production MCP server, three server-side gates decide what an AI agent can create, write and publish. The server connects AI agents to the CMS that runs this website. Its 164 tools (as of 20 October 2026) cover pages, content, SEO and GEO (generative engine optimization, that is, visibility in AI answers), schema.org, media, menus, redirects, Search Console and GA4 analytics, and leads. Access tokens and the call log are managed in the Wagtail admin panel. We have no business metrics from this deployment.

Checklist for CTOs: hard gates on an MCP server exposed to AI agents

No page without a strategy brief. Calling create_page without a strategy, which ties the page to a goal in our content plan and to its role in the sales funnel, returns HTTP 400.
No content before human approval. Writing content while the brief has not been approved by a person returns HTTP 409.
No publication while the audit has errors. Publishing returns HTTP 409 when the audit finds facts outside the approved checklist, client names covered by an NDA or no verdict from an independent critic agent.

No tool on the server has a parameter that skips these gates. The gates have two exceptions: a correction mode for pages that are already live, which publishes a draft only when its audit finds nothing worse than the live version, and manual publication by a person in the Wagtail admin panel.

MCP security best practices from our production server

Put the rules the agent must not break in the server. An instruction in the prompt asks the model to follow a rule; a response code or a validation step on the server enforces it. We keep the rules in HTTP codes and validation, and the prompt only explains them.

Give every agent its own token and log every call. Each agent gets its own token, so every entry in the call log points to one agent and answers the question "which agent did what".

Split the public scope from the authenticated one. Since 8 October 2026 we have also run a public MCP endpoint for AI assistants at https://ordergroup.co/mcp. It needs no token and offers only reading and contact, through two tools: list_case_studies and submit_project_enquiry. It is listed in the official MCP registry as co.ordergroup/public (status active, version 1.0.0, published 8 October 2026). Writing to the CMS is possible only with a token, so an agent without authorization can read and send an enquiry and nothing more.

MCP vs API: frequently asked questions

What is the difference between MCP and an API?

An API exposes fixed endpoints for a programmer who knows the operations in advance. An MCP server publishes a list of tools, each with a name, a description and an input schema, and an AI client asks what is available and lets the model choose. In production the two usually work together.

Does MCP replace APIs?

No. MCP adds a layer for AI agents on top of the systems you already have. In many production setups the MCP server calls an existing API underneath, so the API stays the boundary of the service and MCP becomes the boundary of the agent.

When should you use MCP instead of an API?

Use MCP when an AI agent or assistant such as ChatGPT, Claude or Cursor will work with your system and has to pick tools from their descriptions, or when one server should serve many AI clients. When a programmer writes a system-to-system integration with a stable contract, an API is enough.

Is MCP secure?

The protocol builds in some protection: the host enforces user consent and policies, and a server does not see the full conversation or other servers. The rest depends on the server. The official guide lists attacks such as confused deputy, token passthrough and server-side request forgery, each with mitigations.

What are MCP security best practices?

Keep the rules an agent must not break on the server as response codes and validation. Give every agent its own token and log every call. Separate a public read-only scope from the authenticated one, and ask for the smallest scope first, raising permissions only when an operation needs them.

Is MCP only for Claude?

No. Anthropic created MCP, but in December 2025 it handed the protocol to the Agentic AI Foundation, hosted by the Linux Foundation. According to the same announcement, ChatGPT, Cursor, Gemini, Microsoft Copilot and Visual Studio Code also support MCP.

Next steps

If you are deciding whether your product needs an MCP server, an API or both, see our MCP server development services, our AI agent development services, our AI software development services or book a free consultation.

Originally published at ordergroup.co.

CCD2 for Lending Apps: What Changes in Your Loan Application Flow on 20 November 2026

Filip Szamborski — Sun, 18 Oct 2026 01:30:47 +0000

CCD2 is the common name for Directive (EU) 2023/2225 of 18 October 2023 on credit agreements for consumers, which replaces Directive 2008/48/EC. National rules are due to apply from 20 November 2026, but several member states, Poland among them, will not have a law in place by then. Most of the changes land in the digital product: application screens, consents, messages and automated decisions. That puts CCD2 on the product team's roadmap as much as on the legal department's desk.

Below, each requirement is mapped to the screen, process or data in a loan app that it changes, so a product team can see where the work lands. We stay on the product side: which rules apply to your product, and how, is for your lawyer to judge.

What is CCD2 (the Consumer Credit Directive 2)?

CCD2 is Directive (EU) 2023/2225, published in the Official Journal on 30 October 2023. Member states had until 20 November 2025 to write it into national law and must apply those rules from 20 November 2026 (Article 48).

It is a directive, not a regulation. It does not work on its own: each country writes it into national law, so details differ from market to market.

CCD1 vs CCD2: what moved in the scope

Upper limit: CCD1 covered credit from EUR 200 to EUR 75,000. CCD2 excludes credit above EUR 100,000 (Article 2(2)(c)), with one exception: unsecured loans above that amount taken to renovate a residential property stay in scope (Article 2(3)).
Small amounts: CCD2 has no lower limit, so credit under EUR 200 is now covered.
Interest-free credit: credit granted free of interest and without other charges is in scope.
Buy now, pay later: credit repaid within three months with only insignificant charges, which describes most BNPL products, is in scope.
Lighter regime for these categories: for small, interest-free and three-month credit, member states may switch off a limited set of provisions (Article 2(8)), but the products stay inside the directive.

If your product used to sit outside the consumer credit law, for example a micro-loan under EUR 200 or a deferred payment at checkout, it now goes through the same process as an ordinary loan.

What does CCD2 change in a digital loan application flow?

CCD2 changes four parts of a loan app: advertising, the application, the credit decision and the handling of customers in difficulty.

The items follow the customer journey from the first ad to repayment trouble. For each one: the article, the change in the app, and where that change lives (content, process, or backend and data).

Advertising and acquisition

Cost warning (Article 8(1)): advertising must carry the warning "Caution! Borrowing money costs money" or equivalent wording. In specific, justified cases where an electronic medium cannot show the standard information clearly, part of it may be reached by clicking, scrolling or swiping (Article 8(6)). In the app: the warning and a link to the full data in banners, the calculator, landing pages and push notifications. Where it lives: content; the warning text sits in configuration.
No "credit will fix your finances" (Article 8(7)(a)): advertising may not suggest that credit would improve the consumer's financial situation. In the app: a review of in-app copy and push campaigns. A line like "solve your money problems" has to go. Where it lives: content.

Application

Pre-contractual information (Article 10, Annex I): the Standard European Consumer Credit Information form must be clearly legible, take into account the technical constraints of the medium and display properly across channels (Article 10(6)). Recital 37 adds that the key elements belong in the first part of the form and that the form should work on mobile phone screens. In the app: the form rendered natively from offer data, not only as a PDF. Where it lives: backend and data.
Personalized price (Articles 10(3)(m) and 13): if the price was personalized on the basis of automated processing, including profiling, the pre-contractual information must say so, and the consumer must be told clearly. In the app: a "personalized offer" flag stored as a field on the offer, which every screen reads. Where it lives: backend and data.
Tying banned, bundling allowed (Article 14(1)): you can sell a package, but you cannot make the credit conditional on an extra product. In the app: an add-on such as insurance can be unchecked without blocking the application. Where it lives: process.
No inferred consent (Article 15): default options, including pre-ticked boxes, do not count as agreement; consent needs a clear affirmative act. In the app: zero pre-ticked checkboxes, including in cross-sell and limit-increase screens. Where it lives: process.
No unsolicited credit (Article 17): credit cannot be granted without the consumer's prior request and explicit agreement. In the app: a "pre-approved" offer or a limit increase does not start a credit without the customer's action. Where it lives: process.

Decision

Creditworthiness assessment (Article 18(1)): the creditor must carry out a thorough assessment in the consumer's interest. In the app: every decision can be reconstructed from its input data, the version of the rules or model, and the result. Where it lives: backend and data.
Automated decisions and human intervention (Article 18(8)): when the assessment uses automated processing of personal data, the consumer can request human intervention. That covers a clear explanation of the assessment with the logic and risks involved, the chance to express their point of view, and a review of the assessment and the decision. In the app: a button that starts the request, a queue for an analyst and a record of who changed the decision and when. A clause in the terms and conditions does not give the customer that button. Where it lives: process, backend and data.

After the contract: customers in difficulty

Early detection, debt advice and forbearance (Articles 35(1), 36(2) and 36(3)): creditors need processes to spot consumers in financial difficulty early and to refer them to accessible debt advisory services, and they must apply reasonable forbearance, where appropriate, before enforcement. In the app: signals such as late payments or extension requests captured as data, plus an "I need help" path in the app. Where it lives: backend and data, plus process.

Two items on this list are content changes: warnings and copy. Three are process changes: consents, paths and queues. The other five need backend and data work, such as the offer engine and the decision record, two of them together with process changes. Only that last group cannot be added in a week.

What else lands in the same flow

Directive (EU) 2023/2673 on financial services contracts concluded at a distance applies from 19 June 2026 and requires, among other things, a withdrawal function for contracts concluded through an online interface. Poland has not transposed it yet.
Under the European Accessibility Act, Directive (EU) 2019/882, accessibility requirements for consumer banking services, including consumer credit, apply from 28 June 2025. In Poland they sit in the act of 26 April 2024 on ensuring compliance with accessibility requirements.
Credit scoring of natural persons is a high-risk AI system under the EU AI Act. We cover what that means for lending apps in EU AI Act and Credit Scoring.

Where does transposition stand (and why Poland is a special case)?

State as of October 2026: the transposition deadline passed on 20 November 2025, and member states are at very different stages. The status changes quickly, so check it before you plan a release.

Sweden is an example of a country that is ready. Its new Consumer Credit Act (Konsumentkreditlag, SFS 2026:1011) was adopted by the Riksdag on 27 May 2026 and enters into force on 20 November 2026.

Poland is a special case. The timeline so far:

7 July 2025: the consumer protection office (UOKiK) publishes the first draft of a new consumer credit act.
20-21 January 2026: inter-ministerial consultation meeting on the draft.
5 March 2026: a version dated 25 February 2026 appears on the government legislation portal (RCL).
18 May 2026: the Prime Minister withdraws the UOKiK President's authorization to lead the work.
22 May 2026: the government announces that the draft will be written again from scratch.

The work is now led by the Ministry of Justice together with the Ministry of Finance, and the new act is meant to transpose CCD2 and Directive 2023/2673 at the same time. Poland will not transpose the directive by 20 November 2026 and has told the European Commission so; the aim is to pass the act before the end of the Polish parliament's current term in autumn 2027. At the time of writing, the ministry's draft has not been published; you can follow it in the Council of Ministers' list of legislative work. Until a new act enters into force, the Consumer Credit Act of 12 May 2011 applies in Poland.

What this means for a product team, without legal interpretation: in Poland the date is unknown, and the final shape of the rules will arrive at short notice. If you operate in several EU countries, you will run the same product under different requirements in different markets for a while. That calls for per-market configuration on one codebase. Whether the directive has any direct effect in a country without a national law is a legal question; ask your lawyer.

Why a backend-driven application flow makes CCD2 easier to absorb

A backend-driven flow lets you add a consent screen, a message or a path to an analyst without a new app version or store review.

We have not "implemented CCD2" and we do not claim that the apps below are CCD2-compliant. They are lending apps we build and maintain, and their architecture shows where the requirements from the list above would land.

AvaFin is an iOS and Android app built in React Native that we have been building since January 2026.

AvaFin's central system decides the order of the application steps. After each step the app fetches the current state and works out what to show next, so changing the order or scope of the steps does not need a new app version. That is where a new consent screen, information about a personalized offer or a path to an analyst would go.
When a change does have to ship in code, a minimum-version threshold in Firebase Remote Config forces the update. Once national rules are announced, old versions do not stay in circulation.
The first loan after registration and the next loan for a returning customer run on the same engine. A new requirement changes in one place.
The calculator uses the same pricing engine as the central system, so the amount in the app is the amount in the contract. Advertising, the information form and the contract show the same number.
Analytics and attribution SDKs are off from the first launch and switch on only after the user decides. In September 2026 we adjusted how Crashlytics and Firebase Analytics start to meet the requirements of the client's legal team. Article 15 applies the same principle to credit consents.

Aasa24 is a mobile lending app with card features, developed since 2023 by a dedicated team.

Calculator parameters, documents and messages are managed from an admin panel without a new store version, and card features are switched on remotely with flags. The Article 8 warning and new pre-contractual content become a change in the panel.
Releases ship every 3-4 weeks on average, and production hotfixes ship within days. When a national law lands at short notice, the change goes into the next release or a hotfix instead of waiting for a quarterly cycle.

Pre-contractual content is data and templates, so we test it on edge cases such as empty values or a repeat loan versus a first loan, not only on the happy path. More of this work is described on our fintech software development and mobile app development pages.

A CCD2 readiness checklist for your loan app

A CCD2 readiness check for a loan app covers three areas: content, process, and data and architecture. Answer each question with yes or no; where a question maps to an article, the number is in brackets.

Content

Can you change the "Borrowing money costs money" warning, and the full advertising data behind a click or scroll, without a new app version? (Article 8(1) and 8(6))
Is your in-app and push copy free of suggestions that a loan will improve the customer's finances? (Article 8(7)(a))

Process

Does the backend decide the order of application steps and the scope of fields, so a change skips App Store and Google Play review?
Is every consent box unchecked by default, including in cross-sell, and can an add-on be removed without blocking the application? (Articles 14 and 15)
Does every pre-approved offer and limit increase wait for the customer's action before any credit starts? (Article 17)
Does the customer have a path to a person after an automated decision, handled from a queue that records who changed the decision and when? (Article 18(8))
Can a customer in difficulty find a path to forbearance and debt advice in the app? (Articles 35 and 36)

Data and architecture

Does the information form render legibly on a phone from offer data, not only as a PDF? (Article 10(6))
Do the calculator, the information form and the contract take the price from one engine, and does the offer carry a "personalized" flag? (Articles 10(3)(m) and 13)
Can you reconstruct a creditworthiness decision: input data, version of the rules or model, result? (Article 18)
Do products that used to sit outside the law, such as small amounts and deferred payments, go through the same process? (Article 2)
Can you handle different national requirements through per-market configuration and ship a change in days, not quarters?
Are analytics SDKs off until the user decides?

If you answered "no" or "I don't know" to more than three questions, let's talk about a review of your application flow.

FAQ

What is CCD2?

CCD2 is the common name for Directive (EU) 2023/2225 on credit agreements for consumers. It replaces the 2008 Consumer Credit Directive (2008/48/EC), widens its scope and adds new rules on advertising, consent, creditworthiness assessment and automated decisions. Each EU member state has to write it into national law.

When does CCD2 apply?

Member states had to transpose CCD2 by 20 November 2025 and must apply the national rules from 20 November 2026, under Article 48 of the directive. Several countries, Poland among them, will miss that date, so in practice the start depends on when each national law enters into force.

What is the difference between CCD1 and CCD2?

CCD2 covers credit up to EUR 100,000 with no lower limit, including buy now, pay later. It requires an information form that is legible on a phone and a cost warning in advertising. It bans pre-ticked consent, tying and unsolicited credit, and gives consumers a right to human intervention when an automated system assesses their creditworthiness.

Does CCD2 apply to buy now, pay later?

Yes. Interest-free credit without other charges, and credit repaid within three months with only insignificant charges, both fall within CCD2. Member states may switch off a limited set of provisions for these products under Article 2(8), but the products stay inside the directive and its core rules.

Is CCD2 a directive or a regulation?

CCD2 is a directive, so it needs national laws to take effect in each member state. Until a national law enters into force, the existing consumer credit rules of that country still apply. In Poland, that is the Consumer Credit Act of 12 May 2011.

What does CCD2 mean for a mobile lending app?

A mobile lending app needs an information form that is legible on a phone, cost warnings in its messages, no default consents, a flag for personalized offers and a path to human intervention after an automated decision. If the backend drives the application flow, most of these changes ship without a new store version.

Has Poland implemented CCD2?

No. At the time of writing (October 2026), the Ministry of Justice and the Ministry of Finance are preparing a new draft, and the aim is to pass it before the end of the Polish parliament's current term in autumn 2027. Until then, Poland's Consumer Credit Act of 12 May 2011 applies.

Does CCD2 require human review of automated credit decisions?

When a creditworthiness assessment relies on automated processing of personal data, the consumer can ask for human intervention: an explanation of the assessment, a chance to give their view and a review of the decision (Article 18(8)). In a product, that means a request path in the app and a review queue behind it; a line in the terms and conditions does not provide either.

Originally published at ordergroup.co.

Battery Energy Storage System (BESS): How It Works and What Software It Needs

Filip Szamborski — Wed, 14 Oct 2026 01:08:02 +0000

A battery energy storage system (BESS) is a set of batteries, a power conversion system (PCS), a battery management system (BMS) and an energy management system (EMS) that stores electricity and releases it when it is needed. The IEA counted 108 GW of new BESS capacity in 2025, up 40%. In a BESS, software decides whether storage does its job.

What is a battery energy storage system (BESS)?

A battery energy storage system is a complete installation that charges from the grid or a renewable source, holds the energy in battery cells and discharges it on command. Batteries alone do not make a BESS. Without a PCS to convert current, a BMS to protect the cells and an EMS to decide when to charge and discharge, a rack of batteries cannot serve the grid or a building.

The 108 GW figure for 2025, 40% more than in 2024, comes from the IEA Global Energy Review 2026. An IEA commentary from 29 May 2026 breaks it down:

Around 87 GW of that capacity, roughly four-fifths, was utility-scale. The remaining 21 GW or so was installed behind the meter by businesses and households.
China added just over 63 GW, the United States 19 GW and Europe about 6.2 GW. Europe's total was slightly lower than in 2024, yet its utility-scale additions more than doubled to about 4.6 GW.
The 108 GW added in a single year beat the historical record for annual gas-fired capacity additions, about 107 GW in 2002.

Why grids need storage in the first place is covered in our article on managing surplus renewable energy. The rest of our energy work is collected in the Energy Hub.

MW vs MWh: power and capacity

A BESS has two ratings that are easy to confuse. Power, in megawatts (MW), says how fast the system can charge or discharge. Capacity, in megawatt-hours (MWh), says how much energy it can hold. Divide capacity by power and you get the duration: a 2 MW battery with 4 MWh of capacity can discharge at full power for about two hours.

Durations are getting longer. The IEA commentary reports that the average duration of projects commissioned in 2025 was about three hours, up from about two hours in 2023, with a rising share of projects offering four hours or more.

How does a BESS work?

A BESS works in a loop: it takes AC power from the grid or a solar plant, converts it to DC to charge the cells, then converts it back to AC when it discharges. The PCS does the conversion in both directions. Each layer has its own job in that loop:

The BMS watches the cells: voltage, temperature and state of charge (SoC). It can stop the system if a cell goes out of its safe range.
The EMS decides when to charge, when to discharge and at what power, based on prices, site load, grid operator requests and the limits the BMS reports.
The PCS carries out the EMS setpoint and handles the actual flow of power.

Most systems also expose an operating mode that a person can switch. In the EMS we built for zeronest's prosumer storage, for example, storage control has three modes: Off, Manual and Automatic. Off parks the battery, Manual lets an engineer set charge and discharge by hand, and Automatic hands the decisions to the EMS logic.

What are the main components of a BESS?

The main BESS components are battery cells grouped into modules and racks, a container or enclosure, the PCS, the BMS, the EMS, energy meters and a SCADA and communication layer. The term "BESS battery" usually refers to the cells and racks.

Cells, modules and racks: cells are assembled into modules, and modules into racks. The rack is the unit you see in photos of a BESS.
The BESS container: utility-scale systems usually ship in containers with racks, fire protection and HVAC that keeps the cells in their temperature window.
PCS (inverter): converts AC to DC and back, and executes the power setpoint.
BMS: protects the cells and reports their state.
EMS: makes the charge and discharge decisions for the whole site.
Meters: measure what the site, the solar plant and the battery actually produce and consume. The EMS can only control what it can measure.
SCADA and communication: collect data, show it to people and pass commands between the site, the cloud and the grid operator.

Which battery chemistry do BESS projects use?

Most new BESS projects use lithium iron phosphate (LFP) cells. According to the IEA Global Energy Review 2026, LFP accounts for around 90% of deployments, while five years earlier its share was well below 50%. LFP cells are less energy-dense than the chemistries common in electric vehicles, but they are cheaper and better suited to frequent cycling, and a storage system cycles every day. The IEA commentary also notes that battery costs fell by more than 90% between 2010 and 2025.

BMS vs EMS vs SCADA: who controls what in a BESS?

The BMS protects the cells, the PCS moves the power, the EMS decides what the battery should do and SCADA lets people see and supervise all of it. The layers work on different time scales and usually come from different suppliers, so the interfaces between them have to be designed and tested together. Our article on what BMS means covers the BMS layer in more detail.

BESS control layers compared:

BMS: protects cells (voltage, temperature, SoC, balancing). Time scale: milliseconds to seconds. Usually supplied by the battery manufacturer.
PCS: converts AC/DC and executes power setpoints. Time scale: milliseconds. Usually supplied by the inverter manufacturer.
EMS: decides when to charge and discharge, within site, market and grid limits. Time scale: seconds to hours. Supplied by an integrator, a software house or the battery vendor.
SCADA and monitoring: collects data, shows it to people, logs alarms and passes commands. Time scale: seconds to days. Supplied by the asset owner's platform or an integrator.

For Skyfri, which ran a solar and battery asset management platform, Order Group designed the architecture and built the whole EMS. You can read more in the EMS we built for Skyfri. The EMS went into production in June 2024 and controlled 7 plants, with more than 4 MW of battery power and more than 5 MWh of battery capacity.

The Skyfri EMS:

connects to many types of batteries and inverters and handles several batteries and inverters on one site,
runs fully offline, with no internet connection required to keep controlling the battery,
covers site-level logic: a maximum site load limiter, peak shaving, energy trading and requests from the distribution system operator (DSO).

Its stack is a Python asyncio backend, a React frontend and Azure IoT Edge with IoT Hub, and it was validated at the Socomec battery laboratory in Strasbourg. The monitoring layer above it, SolarSCADA and Skyfri Intelligence, was Skyfri's own product.

What does BESS control software have to handle in practice?

BESS control software has to keep the battery inside its physical limits, follow grid operator commands and still do what the owner bought it for. A CTO evaluating an EMS can check it against the functions below. They come from EMS projects we have worked on, including one for a PV and battery operator with sites in Germany and Canada (15 MWh of BESS, 5 MW of PV). The last three are in progress on that project.

SoC limits: the battery should never be pushed above or below the state-of-charge band the owner and the warranty allow.
Deep discharge protection: a separate guard that stops discharging before the cells reach a damaging level, even if a trading or peak shaving rule asks for more.
Active power range: the battery has to stay within the active power range that the PCS and the grid connection allow.
DSO commands and limits: the grid operator can send a direct command or a power limit, and those override trading and peak shaving logic.
Standby loss coverage: a battery that sits idle still loses energy, and the EMS has to cover those losses so the SoC does not drift.
Safety controller: a controller that throttles battery power when measurements leave the safe range.
Site load limiter: the EMS caps the total site load so the connection is never overloaded.
Manual and direct control: engineers need to take over by hand during commissioning and faults.
Simulator: a simulator with manual BESS control lets the team test the logic before it touches a real site.
PID correction of battery power: real batteries do not hit their setpoint exactly, so a PID controller corrects the inaccuracy in delivered power.
Edge plus cloud: the EMS runs on site on edge hardware (a Revolution Pi industrial computer, RevPi) and sends its data to the cloud.
Separate BESS and meter views: web monitoring shows the battery and the meters as separate items.

An off-the-shelf EMS may cover some of these functions and leave out the rest, which is where the build or buy question below starts.

How does a BESS make money?

A BESS earns money by shifting energy in time, cutting peaks and selling flexibility to the grid. According to the IEA commentary, energy shifting was the main application in more than 90% of new projects in 2025, compared with around 40% in 2015.

Energy shifting (arbitrage): charge when electricity is cheap or abundant, discharge when it is expensive. Our guide to energy trading platforms explains the market side.
Peak shaving: discharge during the site's highest demand to lower capacity charges.
Demand side response (DSR): change consumption or discharge on request in exchange for payment.
Balancing services: the frequency containment reserve (FCR) and the automatic and manual frequency restoration reserves (aFRR, mFRR) that the grid operator buys to keep frequency stable.
Co-location with renewables: about 24 GW of new utility-scale storage in 2025, just under 30%, was built alongside renewable plants, according to the IEA.

Build or buy: when does a BESS need custom software?

A BESS can run on the manufacturer's EMS when it has one battery brand, one inverter brand, standard operating modes and a stable internet connection. A custom or extended EMS becomes necessary when any of those assumptions breaks.

Several battery and inverter brands on one site or across a portfolio.
A requirement to keep working offline.
Integration with energy markets and with DSO commands.
Your own control logic, such as a site load limiter or PID power correction.
Your own platform for end customers, with monitoring and reporting on top of the EMS.

Software we have built and support controls [[f:zn-mwh]] of zeronest's prosumer storage, and the EMS behind it supports 16 confirmed inverter brands. It also controls [[f:gg-mwh]] in the BESS of the PV and battery operator mentioned above. Talk to us about custom software development for your storage project, or see the rest of our energy work in the Energy Hub.

FAQ

What does BESS stand for?

BESS stands for battery energy storage system. The term covers the whole installation: battery cells, the power conversion system, the battery management system and the energy management system that controls charging and discharging.

What is the difference between MW and MWh in a battery storage system?

MW is power: how fast the battery can charge or discharge. MWh is capacity: how much energy it holds. A 2 MW battery with 4 MWh of capacity can discharge at full power for about two hours.

How does a BESS container work?

A BESS container holds battery racks together with fire protection and HVAC that keeps the cells at the right temperature. It connects to a PCS, and the BMS and EMS control it from inside or next to the container.

What is the difference between BMS and EMS?

The BMS protects the battery cells by watching voltage, temperature and state of charge. The EMS decides what the battery does: when to charge, when to discharge and at what power, within the limits the BMS reports.

How long can a BESS discharge?

It depends on the ratio of capacity to power. The IEA reports that projects commissioned in 2025 had an average duration of about three hours, and a growing share of projects offer four hours or more.

Can a BESS work without an internet connection?

Yes, if its EMS runs locally. The EMS we built for Skyfri ran fully offline and kept controlling batteries and inverters without an internet connection.

Is energy storage only about batteries?

No. Energy can also be stored as heat. Our KYOTO case study describes Industrial IoT and a digital twin for a thermal energy storage system.

Originally published at ordergroup.co.

Comparing Ionic, NativeScript & React Native

Filip Szamborski — Thu, 08 Oct 2026 10:39:17 +0000

When it comes to creating apps with JavaScript, there are multiple approaches, and none is more popular than React Native. Some of the biggest apps on both the App Store & Play Store rely on React Native, Ionic is quite popular as well, and NativeScript is behind the two. We also use Meta's framework for creating cross-platform native apps. Curious why?

React Native

React Native is currently the most popular JavaScript framework for creating mobile apps. Neither Ionic nor NativeScript can match its popularity. Its popularity comes from the fact that it was tied to React from the start, while both Ionic and NativeScript were Angular-first (the bet did not pay off for the two).

The framework allows developers to build mobile apps using JavaScript & TypeScript and React's JSX syntax, so you can build rich user interfaces that feel native. You may even reuse the same libraries you are used to from web React, such as Formik, Redux, react-query or even tailwind (provided you install an additional plugin for handling utility classes).

When to Use It

In our view, if you're choosing between those three, you can't go wrong with React Native. It's flexible, the community support is great, and there are a ton of libraries and resources available. If the bare workflow does not suit you, you have Expo at your disposal - a great project that extends Meta's framework and adds many indispensable goodies.

What's becoming more important is that the number of React Native projects is huge, which means tools such as GitHub Copilot, Cursor, and others have more repositories to scrape, so suggestions for your code should be better.

Ionic

Ionic allows the creation of hybrid applications using web technologies like HTML, CSS, and JavaScript. The framework wraps the web application in a native container using Capacitor, thanks to which you may access native APIs from the comfort of the DOM. Because of that, however, apps will be much slower.

Of the 3 frameworks, Ionic will be the easiest to switch to for a web developer, because React Native and NativeScript have some gotchas you need to keep in mind. How many you hit depends on how deep you go, but there are definitely some.

When to Use It

Ionic is great if you want to create quick prototypes or a quick mobile app version of your website, and don't need a performance beast. It's also great for reusing as much code as you can between your web and mobile app.

If your company is primarily a Vue.js or Angular development company, you're effectively choosing between Ionic and NativeScript.

NativeScript

NativeScript (originally called Telerik NativeScript) enables developers to create truly native mobile applications using JavaScript or TypeScript. Unlike Ionic, it does not use WebView but accesses native APIs directly. If you know you will need plenty of third-party libraries, NativeScript isn't for you. The community isn't huge, and it likely won't grow; at least nothing indicates it will. A huge pro is that it has first-party integration with many frameworks.

When to Use It

NativeScript is the least popular of the 3, but it's still not a bad option. You will have significantly fewer third-party plugins and libraries at your disposal, but maybe you won't mind. Furthermore, it offers integrations with 6 different web frameworks, not counting the option of vanilla JavaScript & TypeScript.

If your company primarily uses Vue.js, Angular, Svelte, or Solid, go for it. If you know ahead of time that you won't be using many third-party UI components and such, it's safe to pick. If you do expect to use them, consider a different framework.

React Native vs Ionic vs NativeScript

While choosing the tool matters less than other business decisions, it's still an important decision that could make or break your project. Depending on the type of your app, it can have a big impact on the user experience you deliver.

User Experience

React Native provides a truly native look and feel, as it uses native components for rendering. This results in smoother animations and transitions, making it ideal for performance-sensitive applications.

NativeScript also offers a native experience, allowing direct access to native APIs, which can enhance the app's responsiveness and overall user satisfaction.

Ionic, while capable of creating visually appealing applications, often resembles mobile websites more than native apps because it relies on WebView. This can limit performance in complex applications, and the user interfaces look similar to native ones but feel slightly off.

Development Speed

Ionic is generally faster in development for developers familiar with web technologies (HTML, CSS, JavaScript), making it a preferred choice for rapid prototyping and simpler applications that aren't performance critical.

React Native and NativeScript may require more time to master due to their more complex setups and the need for understanding native mobile development concepts.

Performance

React Native and NativeScript are designed for high performance close to that of native applications. If you're developing graphics-intensive, complex applications, choose one of these two. You should also choose one of them if smooth 60 frames per second is a priority.

Ionic, while effective for simpler apps, can struggle with performance under heavy loads or when utilizing extensive animations.

Community and Ecosystem

Both React Native and Ionic have large communities with plenty of resources, libraries, and third-party plugins that can speed up development.

NativeScript has a smaller community but still offers useful resources and support, particularly for developers who want to use native capabilities.

In the 2024 Stack Overflow Developer Survey, 9% of professional developers declared they're using React Native, 2.8% declared they are using Ionic, and... NativeScript wasn't there. According to the same survey, 56.5% of professional developers "admired" React Native, while 39.6% "admired" Ionic.

When it comes to popularity on GitHub, React Native's repository has 119k stars, NativeScript's repo has 24.2k stars, while Ionic's has more than double that with 51.1k.

Cross-Platform Compatibility

All three frameworks allow for cross-platform development, but the extent of code reuse varies. React Native and NativeScript can share a significant portion of code between iOS and Android. Meta's mobile app framework has one significant pro: you may also create desktop apps for macOS & Windows.

Ionic allows broader code reuse across web, mobile, and desktop platforms but may require additional adjustments for optimal performance on mobile phones. Keep in mind that desktop apps created with Ionic are based on Electron, which is great for development speed but uses too many resources. For example, Slack, a popular messaging app, will easily use 500 MB of your RAM without breaking a sweat.

Summary

The three frameworks approach mobile app development differently, each catering to different developer groups and companies. React Native focuses on creating high-performance, native-like applications using React only. It's ideal for teams & companies familiar with React that want to use native capabilities. Ionic uses web technologies (HTML, CSS, JavaScript) to build hybrid applications that run in a WebView. It's best for rapid prototyping and simpler applications where development speed matters more than native performance, and it's great for web developers moving to mobile. Performance can be a limitation for more complex apps, but it is very accessible for web developers. Lastly, NativeScript provides a way to create truly native apps using JavaScript or TypeScript, accessing native APIs directly. It's suitable for applications that make extensive use of native features, and while it offers a good balance between performance and flexibility, it may not have as large a community or ecosystem as React Native or Ionic.

The choice among React Native, Ionic, and NativeScript should depend on your project requirements, team expertise, and desired user experience. Each framework has its own strengths and weaknesses and its own ratio of development time to UX, so understanding your goals will help you make the best decision for your mobile app.

For us, as well as for a large portion of other companies, there is no better choice than React Native. We love React, and we have created apps using both the native version and the web one. If you need an experienced React & React Native development company, feel free to contact us. You can also see our Expo setup on GitHub.

Originally published at ordergroup.co.

Supercharging PoC Development with AI: A Smarter, Faster Approach

Filip Szamborski — Thu, 08 Oct 2026 10:39:16 +0000

Being able to validate ideas quickly and bring concepts to life matters a lot in software development. Proof of Concept (PoC) development lets you test hypotheses, gather feedback, and make informed decisions before committing significant resources. However, traditional PoC processes can be time-consuming, often getting bogged down in repetitive tasks and coordination problems between frontend and backend teams.

AI-assisted development changes this. New tools can drastically accelerate the prototyping phase, allowing teams to iterate faster and focus on core value propositions. Today, we'll look at a workflow that uses two such tools: v0.dev for frontend generation and Cursor IDE for backend implementation. This combination promises speed and a more streamlined path from idea to functional prototype.

The Challenge: Bridging the Frontend-Backend Gap in PoCs

One common bottleneck in PoC development is the synchronization between the user interface (UI) and the underlying logic and data handling (backend). Often, frontend development proceeds based on initial assumptions, only to require significant backend adjustments later, or vice-versa. This friction slows down iteration cycles and can obscure the core concept being tested.

Introducing the AI-Powered Duo

v0.dev: Your AI Frontend Kick-starter v0.dev, from the creators of Next.js (Vercel), is a generative AI tool built for creating web UIs. From simple text prompts or even Figma designs, v0 generates production-quality React components based on popular libraries like Shadcn UI and Tailwind CSS. It is good at turning ideas into interactive interfaces quickly, so you can see and iterate on them right away. Need a complex dashboard layout or a multi-step onboarding form? Describe it to v0, and it will generate the initial code, often surprisingly close to what you need. Its Figma integration also speeds up the process for design-driven teams.
Cursor IDE: The AI-Native Code Environment Cursor is an AI-first code editor built on VS Code. It integrates Large Language Models (LLMs) directly into the development workflow, with features that go well beyond simple code completion. Cursor understands the context of your entire codebase, so it can generate code, refactor existing logic, debug errors, and even answer questions about your project. Its "Agent" functionality, now the default interaction mode, lets developers delegate tasks to the AI in natural language, which significantly speeds up work that would traditionally require manual coding. Cursor offers access to various models; Anthropic's Claude 3.7 Sonnet provides a strong balance of performance and reasoning, while Google's Gemini 2.5 Pro is also available for complex coding challenges.

The Workflow: Frontend-First, AI-Accelerated

Our proposed workflow uses both tools one after the other, with a tight integration between them:

Step 1: Crafting the UI with v0.dev

Prompt or Design: Start by describing the desired UI components or pages to v0.dev using natural language prompts. Alternatively, import existing Figma designs to provide a visual starting point.
Generate & Iterate: v0 generates React code (typically using Shadcn UI/Tailwind CSS) and, importantly, provides an interactive preview alongside the code. You can immediately see how the generated components look and feel, which gives you fast visual feedback. Refine the UI by providing follow-up prompts, tweaking styles, or modifying component structures directly in the preview or code until the frontend closely matches the PoC requirements.
Export Code: Once satisfied, copy the generated React code. Besides the visual layer, this code implicitly defines the data requirements and interactions needed from the backend.

Step 2: Building Backend Endpoints with Cursor IDE

Import & Contextualize: Bring the v0-generated frontend code into your Cursor IDE project. Cursor's AI can analyze this code, understanding the component props, state management, and data fetching needs. You can use features like @codebase or tag specific files to give the AI the necessary context.
Generate Endpoints: Use Cursor's Agent or inline editing features (Cmd+K/Ctrl+K) to generate the corresponding backend API endpoints. For example, you might select a frontend form component and instruct the Agent: "Generate a Python/Django API endpoint to handle the submission of this form data, including validation based on the component's props." The Agent can directly modify files, run commands, and even iterate on errors.
Refine & Connect: Cursor will generate the backend code (e.g., Django views/serializers, FastAPI endpoints). Review and refine the generated code, adding specific business logic or database interactions as needed. Cursor can help with this refinement as well, keeping the frontend and backend in sync.

Why This Workflow Excels for PoCs

Unprecedented Speed: AI handles much of the boilerplate for both the frontend UI (with immediate visual feedback via interactive previews in v0) and basic backend scaffolding, which drastically reduces development time. Teams can build and test concepts in days rather than weeks.
Reduced Friction: The frontend-first approach ensures the backend is built to directly support the UI's actual needs, minimizing integration issues and rework.
Focus on Core Logic: By automating UI generation and basic endpoint creation, developers can concentrate on the unique business logic and core functionality that differentiates the PoC.
Consistency: v0 often uses standardized component libraries (like Shadcn UI), which keeps the UI consistent, while Cursor can be guided to follow project-specific coding standards using .cursorrules.
Improved Collaboration: Designers can see their visions translated into interactive code faster with v0, while developers can bridge the gap to backend functionality more efficiently with Cursor.
Faster Validation & Iteration: The speed gained allows for quicker feedback loops and rapid iteration based on stakeholder input or testing results.

The Future is Collaborative AI

Tools like v0.devand Cursor IDEdo more than replace manual coding: they move developers toward a more collaborative relationship with AI. They act as assistants that handle repetitive tasks, so people can focus on higher-level problem-solving and innovation.

For managers, this means faster time-to-market for new ideas, lower risk thanks to quick validation, and development teams that work more efficiently. For developers, it means working with current technology, doing less tedious work, and spending more time on the creative and challenging parts of software engineering.

Teams that adopt these AI-powered workflows put themselves at the forefront of software development and can build faster.

Originally published at ordergroup.co.

Backend Development in Python. When to Use Django?

Filip Szamborski — Thu, 08 Oct 2026 10:26:27 +0000

Django is one of the most popular web backend frameworks for Python, and for good reason. The project's website says it all in one sentence: "Django makes it easier to build better web apps more quickly and with less code."

Intro

When developing a web backend in Python, you have many good choices. Among full-stack frameworks, there are Django, Masonite, TurboGears, and web2py. If you're looking for something with a smaller footprint, you can choose between FastAPI, Flask, Bottle, and Pyramid.

At some point, you may ask yourself: when should I use Django, then? With so many choices, should I be using it at all?

When to Use Django?

Rapid Development

Developing with Django is fast. Seriously fast. "Django was designed to help developers take applications from concept to completion as quickly as possible." This speed is largely due to its built-in features, such as the admin dashboard, the ORM, easily customizable authentication and authorization, form handling with CSRF protection, and more. The foundations are already in place, so you can move faster without sacrificing much quality.

Furthermore, Django encourages the "Don't Repeat Yourself" (DRY) principle, allowing developers to write less code while achieving more functionality. This is particularly helpful for projects with tight deadlines, where rapid iteration and deployment are essential. It also keeps the project structure consistent, since the framework suggests a typical solution for most problems, so there is no need to reinvent the wheel.

Scalable Applications

If you think Django won't work at a large scale just because Python is a relatively slow language, think again. "Some of the busiest sites on the web leverage Django's ability to quickly and flexibly scale." The framework is designed to handle high-traffic applications with ease. Some of the features that contribute to Django's scalability include:

Caching Framework

Django includes a robust caching framework that makes it a breeze to cache content, views, and entire pages. This caching mechanism helps reduce the load on the server and improves the application's performance. It also integrates with the most common tools, such as Redis and Memcached.

Asynchronous Tasks

Django supports asynchronous tasks through integrations with task queues like Celery. Developers can offload time-consuming tasks to background workers, so the main application stays responsive and scalable.

Load Balancing

Django applications can be easily load-balanced across multiple servers using standard load balancing techniques, such as round-robin or least-connection algorithms. This allows the application to handle increased traffic by distributing the load across multiple servers.

Security

Security in Django

"Django takes security seriously and helps developers avoid many common security mistakes." Security is a critical part of web development, and the team behind the framework makes sure their creation is secure. Django provides built-in protection against various types of attacks. Some of its main security features include:

Cross-Site Scripting (XSS) Protection

Django's template engine automatically escapes all user-provided input, preventing XSS attacks where malicious scripts could be injected into web pages. This feature helps protect the application and its users from potential harm.

Cross-Site Request Forgery (CSRF) Protection

Django includes a robust CSRF protection mechanism that helps prevent unauthorized actions on behalf of a user. This protection is automatically enabled for all POST, PUT, and DELETE requests, making it difficult for attackers to perform unauthorized actions.

SQL Injection Protection

Django's ORM automatically sanitizes database queries, preventing SQL injection attacks. By using parameterized queries and escaping user input, Django ensures that malicious SQL code cannot be executed on the database.

Secure Password Hashing

Django uses secure password hashing algorithms, such as Argon2, to store user passwords. These algorithms are designed to be computationally expensive, making it difficult for attackers to brute-force or crack the hashed passwords.

Secure Headers

Django sets several security-related HTTP headers by default, such as X-Content-Type-Options, X-Frame-Options, and Referrer-Policy. These headers help protect the application and its users by enforcing security policies in web browsers.

API Development

On its own, Django is already very good for API development. You define a model, then define a view that uses JsonResponse from django.http, and on the surface there's usually not much more to it.

If you want, you can also use Django Rest Framework. The addition to Django is a common choice among web app developers who want to write a front-end in, say, Next.js, and also develop a mobile app, among other reasons.

Django REST Framework is really easy to integrate, with the site's documentation listing only three steps to get started: installing it with pip or poetry, adding "rest_framework" to your INSTALLED_APPS setting, and, to get started quickly, adding REST framework's login and logout views to your root "urls.py" file. Django Rest Framework makes building complex APIs easy and fast by providing built-in tools, such as serializers, base views, viewsets and mixins. Combining the last two lets you add endpoints or features simply by adding mixins to your viewset class inheritance.

Which Companies Use Django?

Django is in use at companies that scaled to operate on petabytes of data every day:

Instagram. Django is in use at both Instagram and Threads, running on Cinder, a custom CPython version developed at Meta. Fun fact: Instagram was able to sustain 30 million users with only 3 engineers.
Clubhouse. The popular app was able to handle 1 million requests per minute with only two backend engineers.
Sentry. The popular SaaS handles 20 billion events per month from some of the biggest services, while preparing to handle twice that.
Disqus. The immensely popular user engagement platform runs on Django. You can only imagine how many comments and other items the back-end Python framework must handle.

If you need more proof that Django can work for you and your business, look at this webpage. It lists a multitude of projects of all sizes built with this full-stack framework.

Conclusion

We use Django because it is scalable, secure, and efficient for developers, even though ticking all these boxes at the same time can seem impossible. It's all thanks to the solid foundations you can easily build on. We have successfully developed many projects using this Python framework and have no plans to give up on it. It lets us write great services quickly while maintaining high quality. If you'd like to discuss working together, do not hesitate to contact us.

Originally published at ordergroup.co.

What Does BMS Mean? Battery & Building Management Systems Explained

Filip Szamborski — Thu, 08 Oct 2026 09:07:02 +0000

BMS most often stands for Battery Management System: the hardware and software that keep a battery or energy store safe, balanced and within its limits. In facility management, the same three letters mean Building Management System, the controller that runs a building's heating, ventilation and access. This guide settles both meanings in the first minute, then digs into the battery and energy-storage side, because that is where we have shipped real systems.

BMS Meaning: What Does BMS Stand For?

BMS has two common meanings, and the right one depends on the industry you work in.

In energy, electric vehicles and grid storage, BMS means Battery Management System: the layer of hardware and software that keeps a battery or energy store working safely. In buildings and facilities, BMS means Building Management System: the control system that runs heating, ventilation, air conditioning, lighting and access across a site.

Here is the fast way to tell them apart:

Battery Management System - monitors and protects an energy store; found in EVs, solar-plus-storage, grid batteries and industrial energy plants.
Building Management System - supervises building services such as HVAC and lighting; found in offices, factories, hospitals and commercial property.

The rest of this article is about the Battery Management System, because that is the system our engineers design and build. The building-management sense gets its own short, honest section below, where we have no project to claim.

What Is a Battery Management System (BMS)?

A Battery Management System is the control layer that keeps an energy store safe, balanced and inside its operating limits.

The store might be a pack of lithium-ion cells in a car, a container of grid batteries, or something far less obvious. Whatever it holds, the BMS has the same job: measure the true state of the store, protect it from damage, and report clean data to the systems above it. In practice that breaks down into a few concrete functions.

State of charge - how much energy is available right now, so operators and higher-level software can plan around it.
Cell and zone balancing - stopping individual cells or regions from drifting apart, which shortens life and creates hot spots.
Thermal protection - watching temperature and triggering cooling or a slowdown before anything overheats.
Safety cut-off - isolating the store the moment a reading crosses a hard limit.
Communication - passing structured data up to a SCADA system or an energy management layer that makes the commercial calls.

General references such as Wikipedia and battery-hardware vendors describe these functions for chemical cells. The part most guides skip is what a BMS looks like when the store it protects is not a chemical battery at all.

Why Getting a BMS Right Is Hard

A BMS is safety-critical software that has to be right every second, not most of the time.

A dashboard can lag and no one gets hurt. A management system for a large energy store cannot afford that luxury; a missed temperature spike or a late cut-off can damage expensive hardware or worse. That raises the bar in three ways that shape the whole build.

Real time - readings arrive continuously, and the system has to react inside tight windows rather than on a human's schedule.
Integration - the BMS has to talk to industrial hardware and to the plant's control systems, which often speak older, unforgiving protocols.
Trust - operators act on what the system tells them, so the data has to be accurate and the alarms have to be believable.

This is why a BMS is rarely a stand-alone app. It is embedded in a larger platform, and it lives or dies on how well it is wired into everything around it.

How We Built a BMS for Large-Scale Energy Storage

We built a battery management system for a store that holds no chemical battery at all.

The client was Kyoto Group, a Euronext-listed energy company. The store was a thermal energy store based on molten salt, sitting at a concentrated solar power (CSP) plant. Instead of cells and voltages, the "battery" here is heat held in salt. The control problem, though, is the one every BMS solves: know the state of the store, keep it safe, and give accurate data to the systems that run the plant.

Because it is a heat store and not a chemical battery, the precise label for what we delivered is an energy-storage management system, even though the project itself uses the term BMS. We integrated it directly with the plant's SCADA layer, which supervises and controls the industrial process, so storage decisions and plant operations stayed in step.

Alongside it we built a second system: an intelligent surveillance and safety layer using infrared (IR) cameras and image recognition. It works with the BMS and SCADA to catch anomalies that a single sensor reading would miss, such as a hot surface or an object where none should be.

The goal was to manage energy production at the plant, use the thermal store well, and let the operator get more value from the same hardware. You can read the full build - its core elements, the technology behind it, and the outcome - in the Kyoto industrial IoT and digital twin case study.

BMS vs EMS: What Is the Difference?

A BMS protects and reports on the store itself; an EMS decides when to charge, discharge or trade the stored energy.

The BMS keeps the asset healthy. The Energy Management System, or EMS, puts it to commercial use. They sit side by side and swap data all day, yet they answer different questions:

BMS - Is the store safe, and what is its exact state right now?
EMS - Given prices, demand and forecasts, when should we charge, discharge or sell?

We have built the EMS side too. For Skyfri, another energy client, we delivered an Energy Management System that cuts energy costs through trading and peak shaving. If you want the short version of how these acronyms relate, we recorded a plain-language explainer of VPP, EMS and BMS that untangles all three in a few minutes.

Where Battery Management Systems Fit in Industrial IoT

A BMS rarely works alone. It is one embedded subsystem inside a larger industrial IoT platform.

In the project above, the battery management system was part of a wider system that also carried a digital twin of the plant, weather and energy-price data, and a control interface for operators. That is the shape of most heavy-industry work: sensors and controllers at the edge, a dependable data pipeline in the middle, and software on top that turns raw readings into decisions.

Designing that full chain - the embedded control, the SCADA integration, and the analytics above it - is what we do in our IoT and device software practice and our energy platform practice. A BMS is usually the point where the two meet.

The Other BMS: Building Management Systems

If you arrived here from the facility side, a Building Management System is the software that runs a building's HVAC, lighting, metering and access from one console.

It shares the BMS name and the same broad idea, one control layer over many devices, but it is a separate field with its own vendors and standards. We do not build facility BMS software, and we would rather say so than pretend. Our work sits on the energy and battery side described above.

Common Questions About BMS

What does BMS mean in engineering?

In engineering, BMS almost always means Battery Management System: the electronics and software that monitor and protect a battery or energy store. Context tells you whether someone means that sense or the building-automation one.

Is BMS the same as EMS?

No. A BMS keeps the energy store safe and reports its state, while an EMS decides when to charge, discharge or trade that energy. They work together but solve different problems.

What does BMS mean in a building?

In a building, BMS means Building Management System: the central controller for heating, ventilation, air conditioning, lighting and access. Beyond the shared acronym, it has nothing to do with batteries.

Who builds custom BMS software?

Software teams with real energy and industrial IoT experience build custom BMS software. We have delivered a SCADA-integrated BMS for a large-scale thermal energy store and an EMS for an energy trading client, and we are glad to talk through your case.

Working on energy storage, a solar or grid project, or an industrial control system that needs a dependable BMS? Talk to our energy team about a free technical consultation.

Originally published at ordergroup.co.