A compliance operating model for a payments firm: putting GDPR, BSA and DORA together

A payments firm does not have three separate compliance problems, it has one operating model with three lenses. GDPR governs the customer data in every payment. The Bank Secrecy Act and the anti-money-laundering directives govern who the customer is and whether the payment is suspicious. DORA governs whether the service stays up and how it recovers. A compliance operating model brings these together into one set of roles, one set of controls, and one set of reports, so that a single payment is screened once, logged once, and reported through one pipeline. The operating model starts with the three lines of defence. The first line is the business and operations teams who process payments, apply the screening rules, and handle the exceptions. The second line is the compliance and risk teams who set the policies, test the controls, and report to the board. The third line is internal audit, which checks independently whether the first two lines work. A business analyst must be able to say, for every requirement, which line owns it, who approves a change to it, and who tests it. Controls must be mapped to the risks they address, and the mapping must be testable. A screening control maps to the risk of processing a payment for a sanctioned person. A data minimisation control maps to the risk of exposing a customer's IBAN to an unauthorised user. An impact tolerance maps to the risk of a payment outage harming customers. Each control needs an owner, a frequency, an evidence record, and a test that proves it works. A control with no test is a hope, not a control. The compliance calendar is the practical tool that holds the model together. It lists every regulatory deadline: the DORA incident report at 4 hours, 72 hours and one month; the SAR filing at 30 days; the CTR filing at 15 days; the GDPR subject access answer at one month; the annual DORA register of third parties; the annual penetration test; the scheme rulebook update each November. The calendar must be in the requirements, and the system must generate alerts before each deadline, not after it. Regulatory change is a permanent workload, not a project. The EPC publishes a new SEPA rulebook every year. SWIFT publishes a standards release every year. The European Commission proposes new payment legislation every few years. Each change needs an impact assessment, a decision on whether to implement, and a change record. The business analyst owns the impact assessment, and the acceptance criteria for a regulatory change must include a test that proves the new rule is applied and the old rule is retired. The board report is where the operating model is judged. It must show the number of screening alerts and the time to triage, the number of SARs filed and the time to file, the number of data subject requests and the time to answer, the number of incidents and the time to recover, and the number of controls that failed their test. A board report that shows only the number of payments processed is hiding the compliance picture. The requirements must state exactly which metrics the system produces, and the metrics must be calculated automatically, not assembled by hand. For a business analyst, the operating model is the deliverable that ties the whole of this chapter together. The model document must name the three lines of defence, list the controls and their owners, show the compliance calendar, and define the board metrics. The acceptance criteria must include a walkthrough where a single payment is traced from initiation to settlement, and every control that touched it is named, with its evidence. Last reviewed 7 November 2026. Further reading: Regulation (EU) 2016/679; Regulation (EU) 2022/2554; Bank Secrecy Act, 31 USC 5311 to 5330; Fifth Anti-Money-Laundering Directive, Directive (EU) 2018/843; Basel Committee guidance on the three lines of defence.