Program structure

How the training actually runs

Four modules, delivered over a schedule your team sets. Each one ends with a working exercise, not a quiz.

Session by session

What each module covers

01

Data mapping and scope

Teams identify every point where financial data enters, is stored, transformed, or transmitted. This module produces a working data flow diagram used throughout the rest of the program.

  • Cataloging sensitive fields across services
  • Identifying third-party integrations that touch financial data
  • Marking boundaries where encryption and access control matter most
02

The review framework

Participants learn a structured set of review questions covering authentication, authorization, input validation, logging, and data retention, then apply it to real pull requests.

  • Reading a diff with compliance context in mind
  • Distinguishing a stylistic comment from a compliance concern
  • Practicing with anonymized examples drawn from financial applications
03

Documentation and findings

Teams practice writing review findings that explain not just what was flagged, but why it matters and what remediation looks like, in language a non-engineer could follow.

  • Structuring a finding: observation, risk, recommendation
  • Building a lightweight internal review log
  • Keeping records that would be useful during an external audit, without being written for one
04

Independent practice session

The team runs a full review cycle on its own codebase while facilitators observe. Feedback focuses on how well the process transfers without direct facilitation.

  • Assigning review roles within the team
  • Running the review against a real, current pull request
  • Debrief on what worked and what needs adapting for the team's context
Team reviewing a printed data flow diagram tracing financial data across services

Data flow mapping

Understanding where data moves is often the missing step before any code-level review begins.

Engineers discussing review findings written on a shared checklist document

Collaborative reading

Reviews are practiced in pairs and small groups so reasoning gets discussed aloud, not just written down.

Format and pacing

Built around how engineering teams actually schedule time

Flexible cadence

Modules can run as one intensive week or spread across several weeks alongside regular sprint work. Sessions are scheduled around your team's calendar, not a fixed public cohort date.

Small groups

Sessions work best with groups small enough that everyone reviews code aloud during the exercises rather than watching a single demonstration.

Remote or in person

Sessions can be delivered remotely or in person at the Kaohsiung office, depending on what fits the team better.

No external certification claim

Completion is recorded internally for training purposes. The program does not issue or imply any external regulatory certification.

Notebook and laptop displaying review documentation on a wooden desk

Curious how a module maps to your stack

Describe your application and data handling context and we can outline which modules would be most relevant.

Ask about scheduling