Case study
Tier-1 European Bank — Internal Compliance Academy for 8,500 Staff
We consolidated three legacy training systems into one multi-tenant academy across six country operations, cleared internal audit on first review, and got every country live in under 14 weeks.
Summary
A tier-1 European bank consolidated three legacy training systems — one per business line — into a single internal compliance academy. The platform handles mandatory training for AML, fraud, market abuse, GDPR, and risk-domain modules, with audit-grade attempt logs feeding into the bank's existing risk reporting infrastructure.
Headline
100% mandatory training completion · 6-week per-country rollout · audit-cleared on first review
Industry
Banking
Engagement
Custom Build
The challenge
The bank ran three parallel training systems acquired through past M&A, each with its own user base, exam logic and audit format. Internal audit flagged the inconsistency as a compliance risk. The brief: one platform, six country instances with local language and regulator-specific modules, full audit trail, integration with the bank's identity system, and rollout by Q4 the same year.
How we approached it
- Discovery sprint with risk, audit, IT security, and L&D stakeholders to map every regulatory module across the six countries
- Designed a multi-tenant architecture: one platform, six tenants, shared course library plus country-specific overrides
- Built SSO over the bank's existing Azure AD with SCIM provisioning — staff appear and disappear automatically as HR systems update
- Custom audit log architecture: every learner action immutably written to an append-only store, exportable to the bank's risk reporting platform
- Phased rollout by country — earliest tenant live at week 8, last tenant live at week 14
Timeline
- 1
Phase 0 — Discovery sprint
Weeks 1–2
- Stakeholder mapping across risk, audit, IT security, and L&D
- Module inventory across six country operations
- Tenant model decision (single platform vs. federated)
- Written 38-page spec, signed off by all four stakeholder groups
- 2
Phase 1 — Core platform build
Weeks 3–8
- Multi-tenant Postgres schema with row-level tenancy
- Azure AD SSO + SCIM provisioning
- Append-only audit log infrastructure
- First country tenant live in staging
- 3
Phase 2 — Country rollouts
Weeks 8–14
- Country 1 live (week 8) — pilot tenant, 1,200 staff
- Countries 2–4 live (weeks 10–12) — staggered to manage support load
- Countries 5–6 live (week 14)
- Audit log streaming integrated with bank's risk platform
- 4
Phase 3 — Operational handover
Weeks 14–18 (post-launch)
- Knowledge transfer to internal L&D ops team
- Runbook + escalation matrix
- 90-day support window with named on-call
- Retainer transition for ongoing roadmap
Outcomes
- 100% completion of mandatory training in the first cycle (vs. 78% on the legacy systems)
- Three legacy systems decommissioned with zero learner data loss
- Internal audit cleared the platform on first review
- Country rollout averaged 6 weeks per tenant after the first one shipped
- Bank's L&D team operates the platform day-to-day; Bitloom retainer covers escalations and roadmap
Why this engagement happened
Most compliance platforms inside large banks are accidents of M&A. A bank acquires another bank; both sides bring their own training infrastructure; the integration roadmap puts platform consolidation in year three; year three never arrives. Five years on, the L&D team is running three systems in parallel, the audit team cannot get a single view of who has completed what, and the cost of doing nothing keeps creeping up.
That was the situation when this engagement started. Internal audit had flagged the inconsistency as a moderate-risk finding — not severe enough to halt operations, but severe enough that the next regulatory inspection would almost certainly escalate it. The L&D and risk teams had a budget and a Q4 deadline. They had also burned €450k on a previous consolidation attempt that had been cancelled in month nine.
We were the third vendor they spoke to. The pitch they bought, in the end, was unromantic: small named team, fixed scope, written change-control, and a phased country rollout that would not put eight thousand staff on a new platform on the same day.
The architecture decision that mattered
Multi-tenancy was the first big decision. The obvious option — six separate instances, one per country, with shared course content syncing between them — was simpler to build but a nightmare to operate. Six deployment pipelines, six monitoring dashboards, six possible places for an audit-log gap to appear.
We pitched the opposite: one platform, six tenants, row-level tenancy in Postgres, country-specific overrides held in a single config table. Operations team owns one system, audit team gets one log, the bank’s risk platform consumes one stream. The downside is that a bug in shared infrastructure affects all six countries — but a bug in shared infrastructure also gets caught by automated tests once instead of six times, and the audit log architecture detects drift before it reaches production.
The bank’s IT security team pushed back on the shared-tenant model for the first two weeks of discovery. We did the work to show that row-level tenancy with explicit tenant_id checks at every query boundary, plus an audit-log invariant test in CI, met their isolation requirements. The IT security lead signed off on the architecture before the build phase started — without that, this would have been a different project.
What almost broke
Two near-misses worth being honest about.
The audit-log handoff to the bank’s risk platform was added in Phase 2. It should have been Phase 0. The risk platform team had a different schema in mind than what our event model produced; reconciling that took three weeks of unplanned work and shifted the timeline forward by ten days. We have since changed our discovery template — any downstream regulated system that consumes our output is now a hard Phase 0 dependency, with a sample integration shipped before any other work starts.
Country 4 had an authentication edge case with a pre-existing local Azure AD tenant that did not match the parent bank’s tenant graph. We discovered it in the staging cutover, two days before go-live for that country. We delayed Country 4 by a week, kept Countries 1–3 on schedule, and used the extra time to write a runbook for similar edge cases at the remaining two countries. Both of them shipped on time.
What handover looked like
The bank operates the platform now. The L&D ops team handles day-to-day learner support, content updates, cohort scheduling, and report generation. Bitloom is on retainer for escalations, platform-level changes, and quarterly roadmap planning.
Knowledge transfer was a deliberate two-day session with the bank’s L&D engineers, not a documentation drop. The runbook covers operations, the architecture diagram covers structure, but the call we picked up at 8am the morning after Country 1 went live taught the L&D engineers more about the system than any written artefact could.
Internal audit cleared the platform on first review six weeks after the last country shipped. The audit pack export — built in Phase 1 because we had argued for it in Phase 0 — gave the audit team exactly the format they had asked for, which was the format we had agreed with them in week two of discovery. None of that was an accident.
What we learned
- Doing all six countries in parallel would have killed us. Staggering by ~2 weeks per tenant let support absorb the launches.
- SCIM provisioning is the unsung hero of large-enterprise rollouts. Without it, the L&D team would have spent the first 90 days reconciling user lists.
- The audit log going into the bank's risk platform was a late-add and the riskiest piece of the project. Lesson: any handoff to a downstream regulated system should be a Phase 0 dependency, not Phase 2.
- Internal audit cleared us on first review because we showed up with the audit-pack format pre-agreed in Phase 0. That conversation saved approximately one quarter of back-and-forth.
Want fuller details under MNDA?
On request we share extended versions of NDA cases with named clients, architecture diagrams and full delivery numbers, under a mutual non-disclosure.