Safety Norms: FinTech Fundamentals

1Purpose, Scope, and Safety Principles

These norms protect learners, instructors, customers whose data appears in case studies, and the wider public from harm caused by poor handling of money, personal information, and financial software. The course covers concepts rather than live trading or lending, so the main hazards are data exposure, credential misuse, unfair treatment of customers, and reliance on untested financial advice. The norms apply to classroom sessions, online labs, sandbox accounts, shared repositories, and any case work using real or realistic financial records.

Three principles guide every rule. First, use synthetic or approved data unless a documented authorization exists. Second, never let a tool, model, or demonstration move real money or change a real account. Third, escalate uncertainty rather than guessing, because a wrong answer about payments or lending can affect many people.

2Roles, Competence, and Accountability

The course sponsor owns this document and approves local procedures. The lead instructor is responsible for lab design, approved data sets, and enforcing rules during sessions. A compliance or information security contact reviews any use of real customer data, sandbox credentials, or third-party platforms. Each learner is accountable for following these norms and reporting problems promptly.

Competence matters. Learners should complete the course prerequisites and any institutional privacy and security briefing before using lab accounts. Instructors demonstrating payment flows, lending calculations, or fraud scoring should confirm subject content with qualified practitioners. No one should present legal or tax conclusions as settled without verification.

• Lead instructor: approves each lab, data set, and third-party tool before use.
• Security contact: issues sandbox credentials and revokes them when the course ends.
• Learners: sign the acceptable use statement and complete the privacy briefing first.
• Guest speakers: provide written confirmation that examples are public or anonymized.

3Course-Specific Hazards and Risk Assessment

Risk assessment identifies what can go wrong, who could be affected, how likely it is, and how severe the result would be. Use a simple low, medium, and high scale for likelihood and impact, record the combined rating, and record the control chosen. Reassess whenever a new tool, data source, or lab activity is introduced.

Some risks depend on jurisdiction. Rules on consumer lending, payment services, data protection, anti-money laundering checks, and sanctions screening differ across regions. Treat any statement about a specific legal duty as requiring verification with competent authorities or qualified counsel.

• Exposure of personal or account data through screenshots, shared files, or public code repositories. Likelihood: medium to high. Impact: high. Control: synthetic data only.
• Misuse of sandbox API keys or tokens, which can allow unauthorized calls or cost the institution money. Likelihood: medium. Impact: high. Control: secret storage and rotation.
• Phishing or social engineering aimed at learners working on banking or payment themes. Likelihood: high. Impact: medium. Control: verified contacts and no credential entry from links.
• Unintended real transactions when a demo connects to a live payment processor or brokerage. Likelihood: low. Impact: high. Control: test endpoints only and a written go-live block.
• Unfair or discriminatory outcomes in credit scoring or automated decision examples. Likelihood: medium. Impact: high for affected people. Control: bias review and human decision points in case work.
• Reliance on personal financial advice given in class. Likelihood: medium. Impact: medium. Control: disclaimers and referral to licensed professionals.
• Eye strain, fatigue, and reduced attention during long lab sessions. Likelihood: high. Impact: low. Control: scheduled breaks and a rest interval every hour.

4Preventive Controls and Safe Practices

Mandatory rules are marked as must. Recommendations are marked as should. Learners and instructors must not share credentials, paste real account numbers into notes, or connect lab code to production services. Lab work should be kept in version controlled folders with access limited to the enrolled group.

Safe practice includes careful demonstrations. Live screen sharing should display only sandbox accounts. Presenters should close browser tabs and disable notifications before projecting. Case studies involving customer complaints should have names, addresses, and account details removed during preparation, not during the session.

Money-moving tools deserve extra caution. Before any payment or transfer function runs, confirm the environment label, the recipient test account, and the amount, and confirm the instructor has authorized the step.

• Must: use only synthetic, anonymized, or approved datasets in labs and assignments.
• Must: store API keys and passwords in the approved secrets manager, never in code, slides, or chat messages.
• Must: use test or sandbox endpoints only, with no live payment or brokerage credentials.
• Must: not attempt to bypass authentication, rate limits, or access controls of any platform.
• Must: not give individualized investment, lending, or tax advice to classmates or the public as course output.
• Must: report suspected phishing before clicking links or entering details.
• Should: review generated code, models, and calculations against documented test cases before presenting results.
• Should: record the verification source and version for every regulatory statement used in class.
• Should: use two person review for any content describing fraud detection thresholds or security controls.

5Equipment, Environment, Information, and Protective Safeguards

Equipment for this course usually includes laptops, browsers, sandbox accounts, code editors, spreadsheets, and cloud notebooks. Devices used for lab work should have current operating system updates, automatic screen locks, full disk encryption where the institution requires it, and endpoint protection. Shared lab machines must be cleared of local files and signed out at the end of each session.

Information safeguards apply to both content and records. Store course data in approved systems with role-based access. Do not record student or customer personal information in discussion forums. Privacy notices and retention rules depend on jurisdiction, so confirm them with the institution's privacy officer. Enable multifactor authentication for all platform accounts where available.

Environmental and ergonomic controls are secondary but real. Workstations should have adequate lighting, stable seating, and monitor placement that limits glare. Shoulder surfing is a privacy hazard in open spaces, so sensitive financial demonstrations should occur in private rooms or use privacy screens angled away from the public.

6Incident Reporting, Emergency Response, and Escalation

Report any suspected data exposure, credential leak, unexpected transaction, phishing attempt, or harmful financial advice to the lead instructor and the security contact the same working day. Do not investigate by accessing other accounts or systems. Preserve evidence such as messages, logs, and screenshots, and hand them to the security contact.

Near misses count. A learner who notices a sandbox returning live data, or a demo that could move funds, should report it even if no harm occurred. Near-miss reports are reviewed for patterns and used to improve lab design. Escalate to the course sponsor when an issue affects other courses, third-party platforms, or regulated activity.

• Stop the activity and disconnect the affected lab session if credentials may be exposed.
• Rotate the affected key or password through the approved process and confirm the old credential is revoked.
• Record the time of discovery, people involved, systems affected, and immediate actions taken.
• Notify the data protection or compliance contact when customer data may be involved, because notice duties depend on jurisdiction and timing.
• Call local emergency services for any injury or threat to a person. Financial loss alone is not an emergency service matter but must be reported to the institution.

7Records, Training, Inspection, and Review

Keep a current register of lab environments, approved datasets, tool owners, sandbox accounts, and access lists. Keep signed acceptable use statements and training completion records. Retain incident and near-miss reports according to institutional retention rules, which vary by jurisdiction.

Training should cover data handling, phishing recognition, the difference between education and advice, and the incident process. Refresh it before each new cohort and whenever a lab changes. Inspect labs before each cohort starts: confirm sandbox access is limited, test endpoints are correct, and no real data remains in shared folders.

Review these norms at least once per course cycle and after every reportable incident. Track measures such as data handling findings, late reports, and overdue access removals. Use findings to update controls rather than to blame individuals. Verify changes to laws, standards, or platform terms with competent authorities or qualified professionals before adopting them.

Implementation checklist

• Confirm every lab uses synthetic, anonymized, or approved data before the session starts.
• Verify that all API keys and passwords sit in the approved secrets manager.
• Confirm test endpoints only and that no live payment or brokerage credentials are connected.
• Clear shared screens and notifications before any live demonstration.
• Enable multifactor authentication on every platform account used in the course.
• Report suspected phishing, exposure, or unexpected transactions to the instructor and security contact the same working day.
• Preserve logs and screenshots, but do not investigate beyond your own authorized access.
• Give no individualized investment, lending, or tax advice in class.
• Verify jurisdiction-specific rules with competent authorities or qualified professionals.
• Revoke sandbox access at course end and record the removal.