A sample of the material

What a self-review actually looks at

This page walks through the categories covered in the full training curriculum. It is an overview for orientation, not the complete working checklist provided during the program.

These categories reflect common areas of focus in compliance-aware code review for financial applications generally. They are informational and are not tailored legal or regulatory guidance for any specific organization. Teams should confirm applicable requirements with their own compliance or legal function.

Access and authorization

Does the code enforce the intended permission model consistently, including for administrative or support tooling that touches account records? Are permission checks placed close to the data access itself, rather than only at the interface layer?

Data handling and storage

Is sensitive financial data encrypted in transit and at rest where applicable? Are fields such as account numbers masked or tokenized in logs, error messages, and support tooling?

Input validation and boundaries

Does the change validate inputs at the system boundary rather than assuming upstream services already sanitized them? Are third-party payloads treated as untrusted by default?

Audit logging

Are financially significant actions, such as balance changes or account modifications, logged with enough context to reconstruct what happened later, without capturing more sensitive data than necessary?

Retention and deletion

Does the system respect any defined retention window for sensitive records, and does deletion actually remove data from backups, caches, and downstream systems, not just the primary database?

How it's practiced

Read against real pull requests, not slides

During training, participants apply each category to actual code changes rather than hypothetical snippets. A mentor works alongside newer reviewers during the first pass, then steps back as confidence builds.

Findings are recorded in a shared format so the reasoning behind a comment, not just the comment itself, becomes part of the team's institutional memory.

Mentor guiding a junior engineer through a compliance-focused code review on a laptop screen

Close-up view of code on screen with review comments and highlighted lines

Why the wording matters

A finding is only useful if it explains the reasoning

A comment that simply says "encrypt this" is easy to ignore or misapply. Part of the training focuses on writing comments that state the observation, the risk it relates to, and a workable next step, so the author understands the why behind the change being requested.

Want to see the full working checklist

The complete checklist, along with facilitation notes, is shared with enrolled teams during the second training module.

Review the full curriculum