Secure Account Data

public with sharing class BankAccountService {
    public static List<Bank_Account__c> getAccountsFor(Id userId) {
        return [
            SELECT Id, Balance__c, Status__c
            FROM Bank_Account__c
            WHERE OwnerId = :userId
            WITH SECURITY_ENFORCED
        ];
    }
}

with sharing and WITH SECURITY_ENFORCED are Module 28's exact security mechanisms — for a banking system, enforcing that a user can only see accounts and balances they're actually permitted to see isn't optional polish, it's the whole point of the security lesson finally mattering in a domain where the stakes are obvious.

trigger TransactionValidation on Transaction__c (before insert) {
    Set<Id> accountIds = new Set<Id>();
    for (Transaction__c t : Trigger.new) accountIds.add(t.Bank_Account__c);

    Map<Id, Bank_Account__c> accounts = new Map<Id, Bank_Account__c>(
        [SELECT Id, Balance__c, Status__c FROM Bank_Account__c WHERE Id IN :accountIds]
    );

    for (Transaction__c t : Trigger.new) {
        Bank_Account__c acc = accounts.get(t.Bank_Account__c);
        if (acc.Status__c != 'Active') {
            t.addError('This account is not active and cannot accept transactions.');
        } else if (t.Type__c == 'Withdrawal' && t.Amount__c > acc.Balance__c) {
            t.addError('Insufficient funds for this withdrawal.');
        }
    }
}

This is a separate before insert trigger, deliberately kept apart from Lesson 2's balance-update after insert trigger — Module 24's separation-of-concerns principle, applied here so that validation logic and balance-update logic can each be tested (Lesson 7) and reasoned about independently.

before insert runs, and can call addError() to block the record entirely, before Lesson 2's after insert balance-update trigger ever executes. This ordering guarantee means an invalid overdraft transaction never reaches the balance-update logic at all — it's rejected outright, exactly the fail-safe design a banking system requires.