B2B Software Consulting in London
London's rulebook is two-layered: UK GDPR as amended by the Data (Use and Access) Act 2025, and — if you are FCA-authorised — operational resilience and record-keeping on top. ERPStack is remote-first: we build your custom ERP into AWS eu-west-2, three Availability Zones since 2016, and make every piece of evidence exportable from the PostgreSQL schema.
Quick Answer
In short: custom ERP development in London answers to two rulebooks at once: UK GDPR as amended by the Data (Use and Access) Act 2025, whose main data-protection provisions commenced on 5 February 2026, and, for authorised firms, the FCA's SYSC 15A impact tolerances, live since 31 March 2025. ERPStack builds it remote-first in AWS eu-west-2 — three Availability Zones — with an append-only PostgreSQL audit log an FCA reviewer can export.
Regional Compliance
- UK GDPR and the Data Protection Act 2018, as amended by the Data (Use and Access) Act 2025
- ICO personal data breach reporting within 72 hours; ceiling £17.5m or 4% of turnover
- FCA SYSC 15A operational resilience — impact tolerances since 31 March 2025
- FCA SYSC 9.1.2R five-year MiFID records; SYSC 10A.1.14R taping, five years, seven on request
- Making Tax Digital for Income Tax from 6 April 2026 above £50,000 qualifying income
- Companies House identity verification, a legal requirement since 18 November 2025
Security & Compliance Architecture
London runs two rulebooks at once. UK GDPR, as amended by the Data (Use and Access) Act 2025, applies to everyone; the FCA Handbook applies on top if you are authorised. Both land in the PostgreSQL schema rather than in a policy PDF.
The Act amended UK GDPR, it did not replace it
Royal Assent was 19 June 2025 and the majority of the Part 5 data-protection and privacy provisions commenced on 5 February 2026. For a London deployment the working items are a lawful-basis column in PostgreSQL, a reworked automated-decision log and a complaints queue with its own clock — three tables under Drizzle ORM, not a rewrite of the London ERP.
A 72-hour clock that has to start itself
The ICO wants a notifiable breach reported without undue delay and no later than 72 hours, with the higher ceiling at £17.5 million or 4% of worldwide turnover. ERPStack wires Sentry detection to an append-only PostgreSQL incident row under RBAC, so the London clock starts on a timestamp the London system wrote rather than on a memory reconstructed a week later.
The evidence a London reviewer asks for
Access reviews come from the RBAC tables in PostgreSQL, change history from GitHub Actions, key rotation and network boundaries from Terraform state, incident timelines from Sentry and the Immutable Audit Trail, and retention proof from AWS object storage under a lock. A London ERP that generates its own SOC 2 and ISO 27001 artefacts turns an audit into a query, and an ERPStack build is designed that way from the first migration.
Critical third parties bite on designation
The Bank of England, PRA and FCA published the final critical third parties rules in PS16/24 on 12 November 2024, effective 1 January 2025, but a provider is bound only once HM Treasury designates it. Until then a London firm carries the risk contractually: an exit plan, Terraform and GitHub Actions testing evidence, incident notification.The reporting regime lands 18 March 2027
PS26/2, published 18 March 2026, creates one FCA, PRA and Bank of England regime for operational incident and third-party reporting, in force a year later. A London ERP should already emit an incident timeline, a severity classification and a third-party register straight from PostgreSQL, with Sentry as the London detection source.
Engineering Blueprint
A London build is a residency-and-evidence problem before it is a performance problem. The PostgreSQL primary runs in AWS eu-west-2 — three Availability Zones, live since 2016 — behind Next.js and TypeScript on Vercel, so the transfer question never arises and the FCA evidence never leaves the PostgreSQL schema.
Impact tolerances are a topology, not a policy
FCA firms have had to operate inside their impact tolerances for every important business service since 31 March 2025. That makes the dependency graph the design: each important business service maps to named resources in Terraform, each carries a tolerance in hours, and the tested workaround runs in GitHub Actions. A London supervisor asks for the mapping and the test result; both come out of the repository.
Two retention clocks, one schema
SYSC 9.1.2R keeps MiFID records five years; SYSC 10A.1.14R keeps telephone and electronic communications five years, and up to seven where the FCA asks. ERPStack expresses the pair as a retention policy per record class in PostgreSQL under Drizzle ORM, with AWS object storage under a retention lock, so a London firm never has to argue about which clock a London record fell under.
What a London ERP has to sit beside
Most London buyers are not starting from nothing. SAP S/4HANA or Oracle NetSuite keeps the statutory books, Salesforce or HubSpot holds the pipeline, and the custom ERP takes the part neither can model — joined over a REST or GraphQL API and cut across with a Strangler Fig Migration Pattern rather than a big bang. Microsoft Dynamics 365, Odoo, Sage X3 and Epicor ERP all appear in London mid-market estates, and ERPStack reads from each into PostgreSQL through Drizzle ORM.
What a London build actually runs on
Next.js and TypeScript on Vercel or AWS, a PostgreSQL primary behind Drizzle ORM, RBAC and SSO with short-lived JWT sessions, Redis for queues, an Immutable Audit Trail, Terraform and GitHub Actions in CI, Sentry for observability and Semgrep SAST on every pull request. SOC 2 and ISO 27001 evidence for a London firm comes out of the PostgreSQL schema rather than a spreadsheet, and the whole stack redeploys from the repository into AWS eu-west-2.
Schema-per-tenant, not a tenant column
// Drizzle ORM — tenant isolation with residency on the row
export const tenant = pgSchema('tenant_01');
export const clients = tenant.table('clients', {
id: uuid('id').primaryKey().defaultRandom(),
residency: varchar('residency').default('eu-west-2').notNull(),
retainUntil: timestamp('retain_until', { withTimezone: true }).notNull(),
});Evaluate Your Stack
Take our interactive audit to see if your architecture is ready for operational scale.
Start Free AuditRegional Infrastructure
Infrastructure Region
Latency Metrics
Primary Datacenter
Success Stories in London
Real-Time Fraud Detection Platform
Real-time fraud detection and risk scoring platform
Read Case StudyTarget Industries in London
Frequently Asked Questions
Not as a blanket rule. UK GDPR restricts international transfers, it does not mandate residency, so the real question is whether your regulator or your customer contract adds one. In practice a London build runs in AWS eu-west-2 — three Availability Zones, live since 2016 — because it removes the transfer argument entirely and keeps latency low; the PostgreSQL primary and the Redis cache both stay in London. Where a US processor is genuinely needed we document the transfer mechanism rather than pretending the data never moves.
It amended UK GDPR rather than replacing it. The Act received Royal Assent on 19 June 2025 and the majority of its Part 5 data-protection and privacy provisions commenced on 5 February 2026. For a London build the practical items are recognised legitimate interests, the reworked automated-decision rules and the complaints route — all of which land in the PostgreSQL schema as a lawful-basis column, a decision log and a request queue under RBAC, not as a policy PDF.
Seventy-two hours. The ICO requires a notifiable personal data breach to be reported without undue delay and no later than 72 hours after you become aware of it, with reasons given if you are late. The higher fine ceiling is £17.5 million or 4% of total worldwide annual turnover, whichever is higher. A London ERP therefore needs the detection path instrumented: Sentry alerts, an Immutable Audit Trail in PostgreSQL, and a breach record that starts its own clock.
Firms in scope had until 31 March 2025 to be able to stay within their impact tolerances for every important business service. That turns a London ERP from a feature list into a mapped dependency graph: which services are important, what the tolerance is in hours, and what the tested workaround actually is. We put the mapping in Terraform and the evidence in PostgreSQL, so a supervisor sees a real failover rather than a diagram.
Not yet, but it is announced. The HMRC and DBT consultation ran from 13 February to 7 May 2025, drew 342 responses, and its outcome was published on 26 November 2025; Budget 2025 announced mandatory e-invoicing for all VAT invoices from 2029, with the implementation roadmap due at Budget 2026. A London ERP built now should already emit a structured invoice model from PostgreSQL over a REST API, so the 2029 mandate becomes a mapping exercise rather than a rebuild of the London system.
SYSC 9.1.2R requires a common platform firm to retain records kept under SYSC 9 for its MiFID business for at least five years. Telephone and electronic communication records under SYSC 10A.1.14R are kept five years, and up to seven where the FCA requests them. For a London deployment that is a retention policy per record class in PostgreSQL plus object storage under a retention lock, not a manual archive job.
Only once HM Treasury designates that vendor. The Bank of England, PRA and FCA published the final critical third parties rules in PS16/24 on 12 November 2024 and they took effect on 1 January 2025, but the statutory obligations bite on a provider only when its designation order comes into force. For most London firms the practical consequence today is contractual: exit plans, testing evidence and incident notification written into the agreement.
18 March 2027. The FCA published PS26/2 on 18 March 2026, creating a single FCA, PRA and Bank of England regime for operational incident and third-party reporting, and the rules come into force a year later. A London build should already be able to produce an incident timeline, a severity classification and a third-party register from the database, because that is what the return will ask for.
If your users are sole traders or landlords, yes. Making Tax Digital for Income Tax applies from 6 April 2026 to qualifying income over £50,000, from 6 April 2027 over £30,000, and from 6 April 2028 over £20,000. A London ERP that already stores transactions with the right categories and a digital link to the return avoids a spreadsheet stage; one that stores summaries does not.