Compliance training LMS for a fintech company

The brief

A fintech company needed a learning platform for mandatory training. Their content team produces courses in an authoring tool and exports SCORM packages; they did not want to author inside Moodle. The platform had to look like their brand, keep administrative power in very few hands, tell learners and managers what to do without anyone pressing send, and produce reports in a format their compliance function already used in Excel.

Before and after

The biggest change a learner or admin sees is how little is left on screen. Stock Moodle offers everything; this platform offers exactly what a SCORM learner and a small admin team need.

What I delivered

Platform on AWS

• Moodle 5.2 on AWS, with scheduled backups and a documented restore procedure.
• Separate staging and production environments. Every change was clicked through on staging by the client before it reached production.
• Outgoing mail configured and rehearsed on staging before any learner received a message.

SCORM-only course delivery

• The course experience was reduced to what a SCORM learner needs: open the course, launch the package, see completion. Activity types the client would never use were removed from the picker.
• SCORM settings were standardised (attempts, completion rules, display) so that every course behaves the same regardless of who uploaded it.
• A course template and an upload runbook let the content team publish a new package without a developer.

Restricted admin roles

• Custom roles for content managers, reporting users and support staff, each limited to the capabilities their job needs. Full site administration stays with one nominated account.
• Role definitions documented capability by capability, with the reason for each grant, so the client's security review could sign them off.

Automated mailers

• Scheduled tasks that send enrolment notices, reminders before a due date, overdue notices and completion confirmations, using the client's copy and branding.
• Timing and audience are settings rather than code, so a change in policy does not need a developer.

Reporting to an Excel specification

• The client supplied a spreadsheet layout their compliance team files with. I built reports that produce exactly those columns, in that order, with the same labels and date formats, downloadable on demand and generated on a schedule.
• Report queries were written against Moodle's own APIs and tested against known data so the numbers match what the SCORM packages recorded.

Brand guideline and theme

• A Boost child theme implemented from the client's brand guideline: colour, type, logo use, login page and email templates.
• Nothing in core was edited. The theme survives Moodle upgrades and the client owns it.

A second, cloned platform

• Part-way through, the client needed a second platform for a separate audience with its own branding and its own admin team. I cloned the first platform into a new environment, re-branded it, and separated the data and the roles, with a checklist so a third clone would be routine.

How it ran

• Scope agreed in writing at the start, then delivered in short milestones, each ending with a walkthrough on staging.
• A delivery notice per milestone listing what changed, what to test and what was still open.
• An operations runbook, an admin guide for the content team, and a change log handed over at the end.

What this shows

The client got a platform their own team runs day to day, reporting in the format their compliance function already files, and a second platform that reused the first build's documentation instead of starting again. If your organisation has the same shape of problem, mandatory training, a small admin team and a reporting format you cannot change, this is the kind of build I do.