The context: valuable data behind an access model that no longer held up
Abbrevia S.p.A. is one of Italy’s leading providers of business intelligence and credit risk assessment. Its strategic asset: a proprietary database covering millions of Italian companies, continuously updated with company registry data, financial statements, adverse events, unpaid bills and anomaly reports.
For years this body of information had been accessible through traditional workflows: manual queries, reports on request, periodic batch exports. A model that worked for a certain generation of clients — but that could no longer withstand two converging pressures:
- AML/KYC compliance had become a legal obligation, with strict requirements for audit trails and ongoing counterparty verification for banks, financial intermediaries and payment institutions.
- Clients expected real-time access, not overnight exports. A credit operation cannot wait for a report the following day.
The conclusion was clear: optimising the existing processes was not enough. What was needed was a platform built for the future, not adapted from the past.
The design challenge: multi-product, multi-tenant, mission-critical
The initial brief set out three non-negotiable dimensions.
Multi-product. Abbrevia did not want a single product, but a platform hosting suites of modules with distinct logic — credit risk scoring, information reports, AML/KYC compliance, ongoing monitoring — each with its own pricing, access rules and APIs. The platform had to be extensible: tomorrow’s products could not require rewriting today’s architecture.
Enterprise multi-tenancy. Abbrevia’s clients are supervised financial institutions: banks, intermediaries, factoring companies, payment institutions. Not “consumer” users who tolerate a few hours of downtime or an imprecise audit trail. Every institution demands complete data segregation and the ability to demonstrate to supervisory bodies exactly what was accessed, by whom, when and with what outcome.
Room to scale. The target was 4M+ requests per year, with enterprise peaks to absorb without degradation. But the platform had to be designed to grow without the architecture becoming the bottleneck at the first commercial expansion.
The first decision that mattered was not a technological one: it was drawing the exact boundary between what the platform would handle and what Abbrevia’s underlying systems would keep doing. Getting that line wrong in a multi-product project means growing coupling, expensive refactoring and a roadmap permanently behind schedule.
How we structured the project
Before writing a single line of code: three weeks of discovery and architecture review with Abbrevia’s technical and business teams. The goal was not to produce a document — it was to align expectations on four critical areas:
- The existing data flows and the integration points with Abbrevia’s proprietary databases
- The specific regulatory requirements: AML/KYC, GDPR as applied to the processing of company data, Bank of Italy guidance for supervised intermediaries
- The real usage patterns of enterprise clients (how many requests, in which time windows, with what peaks)
- The non-negotiable performance targets: maximum acceptable latency for real-time queries, availability SLA, recovery time after an outage
Only after this preparatory work could we define an architecture that solved the real problem, not the imagined one.
The architecture: three distinct layers for three distinct responsibilities
The Abbrevia-X platform is structured in three layers with clear-cut responsibilities and well-defined interfaces.
Layer 1 — Data & Integration
An integration layer that abstracts Abbrevia’s underlying data systems, exposing standardised APIs to the application layer. This layer handles query optimisation, intelligent caching for frequently accessed profiles, normalisation of data from heterogeneous sources (company registry data, credit information, adverse events) and refresh management. Changing an underlying data source does not require touching the layer above.
Layer 2 — Product Core
The core of the platform hosts the product modules, each with its own business logic: Credit Risk & Scoring for real-time access to company profiles with multi-dimensional scoring; AML/KYC Module with structured workflows for onboarding, periodic due diligence and ongoing monitoring, immutable audit trail included; Report & BI for generating in-depth information reports; Monitoring for automatic alerting on changes in the profiles of monitored counterparties.
Layer 3 — Tenant Management & Gateway
Multi-tenant access management with complete isolation between clients, API key management, rate limiting by contract plan, billing integration and granular usage analytics per product and per client. This layer is also the entry point for enterprise integrations via API.
The technical choices that made the difference
Event-driven for ongoing monitoring
For the monitoring module covering 6M+ profiles, active polling would have been unsustainable: periodically checking millions of records to spot changes would have required disproportionate computing resources. We adopted an event-driven architecture: when a monitored profile is updated in the underlying systems, an event is emitted and the subscribers configured for that client process it asynchronously. The result: real-time notifications without a computational load that grows linearly with the volume of monitored profiles.
4M+ requests per year handled without active polling across millions of profiles. Event-driven was not a fashionable choice: it was the only sustainable architecture at that scale.
Immutable audit trail for AML compliance
For supervised clients, being able to demonstrate to the authorities when a check was carried out, by whom, on which counterparty and with what outcome is not a nice-to-have requirement: it is a regulatory constraint. Every operation in the AML/KYC module produces a signed, immutable log record, with a certified timestamp, the operator’s identifier, a hash of the data accessed and the outcome of the check. This audit trail can be exported in a standard format for filings with the Bank of Italy and European supervisory bodies.
The crucial design choice: the audit trail was designed as a primary requirement, not added afterwards. Compliance systems that build it as an afterthought are always missing something when the real inspection comes.
Multi-tenancy with complete isolation, not shared tenancy
The operationally cheaper solution — a database schema shared between tenants with row-level security — was not acceptable for supervised financial institutions. Complete segregation costs more in infrastructure and operational overhead, but it is the only architecture that passes a regulatory audit — one that requires proof that no cross-client access is possible — without compromises.
Bulk APIs for enterprise clients
Enterprise clients — banks with portfolios of thousands of counterparties — do not use the platform one request at a time. They need to enrich their internal systems at scale, to import new counterparties in batches and to periodically refresh every monitored profile. We designed bulk APIs with asynchronous job handling, completion notifications, rate limiting by contract plan and a status dashboard, so that standard clients are not penalised during enterprise usage peaks.
The results
The platform is today Abbrevia’s main strategic product, with clients across the entire Italian financial sector: commercial banks, credit intermediaries, factoring companies, payment institutions, corporate advisory firms. The AML/KYC module enabled Abbrevia to enter client segments that previously could not be served for lack of a certifiable compliance workflow.
We have worked with TC Consulting for several years on software development and on projects integrating artificial intelligence. Beyond the technical skills, what really makes the difference is the professionalism of the people: a well-prepared team, available and able to understand business needs in depth. A reliable, results-oriented partner with whom building value over time is straightforward.
What this project taught us
The boundary between platform and product is a strategic choice, not a technical one
The first decision is not “which framework do we use” but “where does the platform end and the product begin”. In a multi-product system, getting that line wrong means progressive coupling that slows down every new piece of development. Spending weeks on discovery before writing code is not a cost: it is the best investment in the project.
In regulated sectors, the audit trail is not a later addition
If you build it as an afterthought — “we’ll add it when we need it” — something is always missing when the real inspection arrives. The audit trail must be designed as a primary architectural requirement, not as a release 2.0 feature. The cost of adding it after the fact is systematically underestimated.
“Real” multi-tenancy is not negotiable in finance
Complete segregation has a higher operational cost than shared tenancy. But in a context where clients are supervised entities, it is the only architecture that survives a regulatory audit without compromises or last-minute workarounds. Saving on infrastructure is not worth the risk of being unable to demonstrate isolation during an inspection.