Four companies. 50+ banks. One platform handling loan origination, bank submission, document generation, commission management, and automated communications, with zero shared data across tenants.
Four Italian financial intermediation companies, each originating loans through networks of partner banks. The daily reality: origination handled in fragmented tools, submissions to banks prepared and sent manually, commission calculations reconciled by hand across companies and bank agreements, documents generated one by one. Every manual step was a compliance surface and a bottleneck, and none of the four companies could share infrastructure without risking sharing data.
Italian financial products are unusually complex, and the platform had to serve four independent companies on shared infrastructure with zero data visibility between them. Bank-side integrations across 50+ institutions, and no two banks integrate the same way: some expose live web services, some accept only scheduled file transfers, most rely on human-readable communication. Regulated domain: auditability and access control were requirements, not features.
One multi-tenant financial operating system covering the full chain: loan origination, the complete dossier lifecycle (subjects, roles, documents, communications, status workflow, mandatory-field and missing-document checks), bank submission, product search across partner banks, document generation, commission management, and automated communications. Tenant isolation enforced at the architecture level from day one, so four companies operate on one platform as if each had its own. Identity and access run on a dedicated layer with an isolated realm per company and role rules managed inside the platform.
Stack: React, Java Spring Boot, TypeScript services, GCP, Keycloak, PostgreSQL, multi-tenant architecture.
Four independent companies operating on shared infrastructure.
Partner banks connected through the network.
Zero data visibility between companies.
Automated submission replaced manual batch processing.
Tenant isolation is an engineering problem; a mis-scoped query must be structurally impossible, not merely unlikely.
Rationale: In fintech, tenant isolation is an engineering problem; a mis-scoped query must be structurally impossible, not merely unlikely.
Trade-off accepted: Heavier upfront data-model and access design, slower first sprint, faster every sprint after.
Fine-grained role rules stay manageable inside the platform's user administration, on top of the identity layer.
Rationale: Access control across four companies and dozens of bank relationships outgrows in-app role tables, and auditability needs a system of record for identity.
Trade-off accepted: One more component to operate.
Every submission routes through a common interface; each bank keeps its own dedicated integration behind it.
Rationale: Adding or changing a bank must never touch core origination logic.
Trade-off accepted: An adapter layer to build and maintain per bank, accepted so that heterogeneity stays at the edge of the system.
We underestimated the ramp into Italian financial products and spent early sprints learning the domain while building. Today we would not start that way, and we don't: a structured discovery phase with the client's own product experts, before any code, is now the first formal step of every engagement. 7Hub is a large part of why our Diagnose phase exists.
7Hub is a long-running platform engagement, multi-tenant fintech infrastructure where regulatory surface, bank heterogeneity, and tenant isolation all had to be engineered from day one.
If you are operating a regulated financial network on shared infrastructure, we can map where manual steps, integration sprawl, or tenant boundaries create risk before you commit build scope.