# Legal & Compliance

Good morning everyone. Kicking off the week with a reminder that our FCA pre-audit self-assessment deadline is end of March. Sam, can you give us a status update on where we stand with the remediation tracker?

Hi Rachel — yes, I've been working through the tracker. We're currently at 14/22 items marked complete. The outstanding 8 are mostly in the AML controls and transaction monitoring categories. I'll have a more detailed breakdown ready by EOD today.

Sharing this for awareness — FCA published updated guidance on operational resilience frameworks last week: https://www.fca.org.uk/publications/policy-statements/ps21-3-building-operational-resilience. Worth a read given our upcoming self-assessment.

Here's the EOD breakdown as promised. Items remaining: (1) AML transaction monitoring thresholds — waiting on engineering config confirmation, (2) Suspicious activity reporting workflow — draft ready, needs legal sign-off, (3) Customer due diligence escalation path — in progress, (4) Data retention schedule — needs IT input, (5) Staff AML training completion — 78% done, (6) PEP screening policy update — draft circulated, (7) Record-keeping audit trail — partial, (8) Cross-border payment controls documentation — not started. Rachel, flagging item 8 as the one I'm least confident about — I'm not sure what scope we need to cover there.

Thanks Sam. Item 8 is going to need input from the product team given the upcoming EU expansion plans. Let's schedule a call this week to go through the blockers together. I'll send a calendar invite.

Quick note — I reviewed the suspicious activity reporting workflow draft (item 2 on Sam's list). I have a few minor comments but nothing blocking. Sam, I'll send redlines to you directly. Should be fine to mark that one as near-complete.

Update on AML training (item 5): chased the HR team this morning. We're now at 84% completion. Remaining staff have been sent a final reminder with a Friday deadline. Should be able to close this one out by end of week.

Flagging this for the group — I've had a preliminary look at the PEP screening policy draft (item 6). The current draft doesn't adequately cover adverse media screening. We need to add a section on that before I can sign off. Sam, can you take a first pass at adding that section? I can share some reference examples from our previous policy version.

Heads up — there's an interesting FCA speech from last week where they signalled increased scrutiny on payment firms' AML controls in 2026. Article here: https://www.fca.org.uk/news/speeches/2026-priorities-payments-sector. Particularly relevant for us given the timing of the audit.

Thanks Maya — I saw this too. The section on transaction monitoring is especially relevant. Sam, worth factoring into how we document our thresholds rationale for item 1 on the tracker. The FCA are clearly expecting firms to show they've actively calibrated their thresholds, not just set them and forgotten about them.

Got it. I've added a note to the tracker. Do we have documentation from engineering on how the current thresholds were set originally? I want to make sure I'm presenting the right narrative to the FCA.

Hey Rachel — saw my name come up. Happy to help with the threshold documentation. Honestly the original thresholds were set a couple of years ago and I don't think anyone wrote down the reasoning. I can put together a technical summary of what the current config looks like and the logic behind the values if that helps?

Tom — yes please, that would be really helpful. A technical summary plus a brief rationale for the current values would give us something to work with. If you can get that to Sam by Wednesday, he can incorporate it into the tracker documentation.

Tracker update for the week: Items 2 (SAR workflow) and 5 (AML training — we hit 100% on Friday) are now marked complete. That takes us to 16/22. Working on items 1, 4, 6, 7, 8 this week. Item 3 (CDD escalation path) is with Rachel for review.

Sam, on item 8 (cross-border payment controls) — I did some research over the weekend. For EU expansion the key frameworks we'd need to cover are PSD2, GDPR data transfer requirements, and local AML transposition in target markets. Happy to draft an initial scope outline if that would help unblock you?

Maya that would be amazing, thank you. I was feeling a bit lost on where to start with that one. Even a rough outline would give me a frame to work from.

CDD escalation path (item 3) reviewed — sending back to Sam with comments. Main issue is the escalation timeframes aren't aligned with our internal SLAs. Needs a small redraft but nothing major.

Done — I've shared the transaction monitoring threshold doc with Rachel and Sam. It covers the current config, the rule logic, and my best reconstruction of why the values were set where they were. Let me know if you need anything else from the engineering side.

Thanks Tom — just reviewed it. Really useful. I'll use this as the basis for the threshold rationale narrative in the audit pack. Rachel, should I get this formally reviewed by you before adding to the tracker?

Cross-border scope outline is done — I've shared it with Sam as a Google Doc. Summary: we'd need coverage across PSD2 licensing in target EU markets, GDPR/SCCs for data transfers, local AML/CTF transposition (varies by country), and SWIFT correspondent banking compliance. I've flagged which ones are 'must-have' for launch vs 'can document post-launch'. Rachel, let me know if you want me to present this to the broader team.

Maya — excellent work, thank you. Sam, use this as your framework for item 8. Maya, let's hold the broader presentation for now — I want to wait until we have a clearer picture of which EU markets product is actually targeting before we go wider.

End of week update: Items 1 (AML thresholds — doc complete, with Rachel for review), 3 (CDD escalation — redraft done, resubmitted), 6 (PEP screening — adverse media section added, back with Rachel). Items 4, 7, 8 still in progress. Overall we're in decent shape for the end-of-month deadline but it's going to be a busy final week.

Understood. Working to that date. Data retention schedule (item 4) is the one I'm most concerned about — we need IT to confirm their current retention configs before I can complete the documentation. I've sent a reminder to Chris but haven't heard back. Rachel, is there someone else I should escalate to?

FYI — ICO updated their data retention guidance for financial services firms last month. Might be relevant as a reference point for item 4: https://ico.org.uk/for-organisations/guide-to-data-protection/retention-schedules/. The section on payment data is particularly useful.

Hey Sam — Rachel looped me in on the data retention question. I've asked Chris to prioritise getting you the retention config documentation today. Sorry for the delay on that, it fell through the cracks with the Atlas sprint. You should hear from him shortly.

Hey Sam — apologies for the slow response. I've just sent you a spreadsheet with our current data retention configs across all environments. Let me know if anything needs clarification.

Thanks Chris — got it. Really helpful. I can complete item 4 now. Rachel, small flag: the production DB retention config shows customer transaction records being purged at 5 years. Our policy document says 6 years. This is a discrepancy we'll need to address before the audit.

Tracker status as of today: 19/22 items complete or near-complete. Items 7 (audit trail record-keeping) and 8 (cross-border docs) are in draft, item 4 is pending the retention config fix from engineering. If all goes to plan we should be able to call it complete by Thursday.

Just to confirm: the retention config has been updated by engineering (thanks Priya). Item 4 is now closed. Sam — priority today is getting items 7 and 8 to a submittable state. I can review in real-time if you share the drafts now.

Sharing both now. Item 7 doc is fairly complete — just needs your sign-off on the audit trail retention period. Item 8 is more of an outline at this stage, drawing on Maya's framework. Let me know if item 8 is detailed enough for submission or if I need to expand it.

Really glad we got there. Thanks everyone — and especially Maya for the cross-border framework, that really unblocked me. Rachel, let me know if you need me to prepare anything else ahead of the board meeting.

Quick share — the FCA updated their supervisory approach for payment institutions page: https://www.fca.org.uk/firms/payment-services. There's a new section on their priorities for 2026 firm visits. Given we just submitted our self-assessment, might be worth bookmarking for context on what they'll likely focus on.

Wanted to add a note here to acknowledge the team's work on the self-assessment. The board was satisfied with the quality of documentation. As Rachel mentioned, I'll be reviewing the action plan once it's circulated. Please continue to keep me informed of any material compliance developments via email.

Quick question Rachel — for the post-audit action plan, should I start preparing a gap analysis against the FCA's operational resilience PS21/3 requirements? Maya shared the guidance a couple of weeks ago and I wasn't sure if that was on our immediate radar or longer-term.

Sharing for the team — PSR (Payment Systems Regulator) published a new consultation paper on APP fraud reimbursement requirements: https://www.psr.org.uk/publications/consultations/2026-app-fraud. The implementation timeline is tight and there are implications for our dispute resolution process. Rachel, should we add this to the action plan?

Maya — yes, add it. This is actually high priority given the timeline. Sam, can you do an initial read of this consultation paper this week and give me a one-page summary of the implications for us by Thursday? I want to have a clear view before I brief James.

Circulating the post-FCA self-assessment action plan — I've drafted this based on Rachel's notes and the items that were flagged as 'further development needed'. Key open items: (1) Operational resilience gap analysis (medium-term), (2) EU expansion compliance framework (dependent on product roadmap), (3) APP fraud reimbursement — new PSR consultation (high priority), (4) Transaction monitoring thresholds annual review (Q3), (5) Data retention automation (see separate thread). Rachel, please review and let me know if I've missed anything.

Good work Sam. One addition — add a standing item for DPIA reviews on new product features and payment flows. We've been reactive on that and I want to formalise the process. I'll speak to Priya about getting compliance looped in earlier on product development cycles.

Heads up — there's been some press coverage this week about the FCA increasing fines for payment firms with inadequate AML controls. Link: https://www.ft.com/content/fca-aml-enforcement-2026. Not directly relevant to us right now but worth tracking given our audit timeline.

APP fraud reimbursement summary is ready — sharing with Rachel now. Short version: the PSR is proposing mandatory reimbursement within 5 days for APP fraud victims, with shared liability between sending and receiving PSPs. Our current dispute process doesn't meet the 5-day threshold and we'd need to update our terms and customer comms. This is going to need input from product, legal and ops. Rachel, happy to discuss when you've had a chance to read.

Thanks Sam — read it. This is significant. The 5-day threshold is going to be a stretch with our current processes. I'll brief James this week and suggest we set up a cross-functional working group. Maya, can you do a more detailed legal analysis of the liability allocation between PSPs? That's the part with the most uncertainty for us.

Rachel — quick question on data retention automation (action plan item 5). I know we flagged it as a longer-term item but given the discrepancy we found during the self-assessment, should we move it up? I was thinking if we automated the retention enforcement we'd eliminate the risk of the policy/config gap recurring.

Rachel — I've checked the DPIA register and there's nothing logged for Atlas. I'll reach out to the Atlas team to find out if one was started informally and just not submitted.

Hey — just saw Rachel's message. I'm on the Atlas team. To my knowledge no DPIA was started. We were told compliance review would happen closer to launch. I may have been given incorrect info on the process though. Happy to help with whatever's needed to get this moving.

Tom — thanks for the quick response and for being honest about the situation. Just want to make sure I'm clear: the DPIA needs to happen *before* launch, not after. It's a GDPR requirement. I'll reach out to the product owner to discuss timeline. Sam, can you send Tom the DPIA template so the Atlas team has it ready to go?

For context on the DPIA requirement — the ICO's guidance on DPIAs for payment processing is pretty clear that any new processing of financial data at scale requires one: https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/accountability-and-governance/data-protection-impact-assessments/. Given Atlas is a new payment flow, this is squarely within scope.

Update on Atlas DPIA: I spoke to the Atlas PM (Daniel Wright). He was under the impression that DPIAs were optional unless we identified a high-risk flag. I've corrected that understanding and shared the ICO guidance Maya linked. He's checking with the engineering team on timeline — will get back to us Monday. Rachel, do you want me to loop you in directly with Daniel?

Also flagging — the EU AI Act has a provision that could touch automated payment decisioning systems. If Atlas has any automated decision-making component (e.g. fraud scoring, credit assessment) we should check whether it falls within scope. Article here: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689. Sam, do you know if Atlas uses any automated decision logic?

Maya — I believe Atlas does have a real-time fraud scoring component. Tom would know more. Tom, can you clarify whether Atlas uses automated decisioning for fraud or anything else?

Following up on Atlas DPIA — I spoke with James yesterday. He has reviewed the situation and indicated that in his view the compliance review can be conducted post-launch as a condition of the launch, rather than as a gate. I want to be transparent: I've raised my disagreement with that position directly with him. Just want to make sure the team is aware of where things stand.

Rachel — for what it's worth I agree with your position. The ICO guidance is pretty unambiguous that a DPIA needs to be completed *before* processing begins. A post-launch review would not satisfy that requirement. I can prepare a short written note summarising the legal position if that would be useful.

Wanted to flag — I've been doing some reading on the EU expansion compliance requirements (action plan item 2). The complexity varies a lot by market. Germany and France are relatively straightforward from a PSD2 perspective since we'd be passporting the UK licence, but post-Brexit the passporting position is no longer valid. We'd potentially need local authorisations. Is this something we should be raising urgently with James?

EU expansion compliance research — some initial findings I want to document here while they're fresh. For Germany: BaFin authorisation likely needed (payment institution licence), timeline ~12 months minimum. France: ACPR equivalent. Netherlands: DNB. Each has local AML implementation nuances. In all cases, GDPR is directly applicable but local data protection authority relationships matter. The operational complexity here is significant. I'll write this up properly but wanted to flag the headline risk: any EU launch is an 18+ month compliance journey from a standing start.

Sam — that timeline sounds right to me. One addition: there may be an e-money institution route that's slightly faster than a full PI licence in some markets, depending on what products we're offering. Worth exploring as a potential parallel track. I'll check and come back to you.

Flagging for this channel's awareness: I've been asked about our EU compliance posture in leadership weekly. We have a live integration processing cross-border EUR payments and the PSD2 assessment is not yet complete. Data transfer mechanisms for EU data subjects are also unconfirmed. Raising now so legal is looped in early — this isn't a drill, we have real transactions flowing.

Rachel — I want to echo this. I've shared the legal note you requested — it's clear that UK GDPR Article 35 requires the DPIA to be undertaken 'prior to the processing'. There's no regulatory basis for treating it as a post-launch activity. I've documented this in the note and will keep a copy. I understand the commercial pressures but I think the exposure here is real.

Rachel and Maya — noted and I agree with your assessment. Is there anything I can do to support? Should I try to get a timeline from the Atlas team on how quickly they could complete a DPIA even at this late stage? If it could be done in a week it might change the calculus on launch timing.

Hey — Sam just messaged me. I can absolutely pull together the data processing inventory and security controls doc for Atlas. It's not that different from what I did for the AML threshold documentation. Give me 2 days and I'll have it to you. Would rather do this properly than launch with a gap.

Tom — that's really appreciated. Please send it to me, Sam, and Maya directly. For transparency: I've also notified James that the team is making an effort to complete this pre-launch on an accelerated basis. The decision on whether to proceed with the original launch timeline vs a brief delay is ultimately his, but I want to give him the option of having a proper DPIA in place first.

Also sharing this — ICO published enforcement action against a UK fintech last week for launching a service without completing a DPIA: https://ico.org.uk/about-the-ico/media-centre/news-and-blogs/2026/enforcement-fintech-dpia. Fine was £180k. Not massive but the reputational risk is worse. Sharing for context — not trying to add pressure, just want the team to have the full picture.

Data retention automation requirements doc is done — sharing with Rachel and Priya. Summary of what we need: (1) Automated enforcement of retention periods at database level per data category, (2) Alerting when data approaches retention expiry, (3) Audit log of all deletion events, (4) Ability to place legal holds that override automatic deletion, (5) Annual review report of retention compliance. Rachel, let me know if this captures everything from the compliance side.

Sam — yes, this covers what we need from a compliance perspective. Point 4 (legal holds) is particularly important — it's often missed in these implementations and then causes problems when litigation or regulatory inquiries come in. Good to have it in from the start. I'll share this with Priya for engineering scoping.

Received Rachel's note on the data retention automation. I've read through Sam's requirements doc — it's clear and actionable. I think we can scope this as a Q2 engineering project. The legal hold feature is the most complex part technically but it's doable. I'll get an engineering estimate and come back to you next week.

Atlas data processing inventory and security controls doc is done — sent to Rachel, Sam, and Maya. It covers all data categories processed by the Atlas payment flow, third-party processors involved, data transfer mechanisms, and the existing security controls. Let me know if there are gaps — I tried to be thorough but some of the historical infrastructure decisions are a bit murky.

Tom — really good work, thank you. Maya and I are starting the DPIA review today. Tom, one follow-up: the doc mentions a third-party fraud scoring API (VerifyFlow). Is that a new processor introduced specifically for Atlas or was it already in use elsewhere?

On it. I'll contact VerifyFlow today. Rachel — separate question: the EU expansion compliance meeting you mentioned a couple of weeks ago. Should we try to schedule that this week or is the Atlas DPIA taking priority right now?

Initial DPIA review is progressing. A few items we need resolved before we can finalise: (1) VerifyFlow transfer mechanism — Sam is chasing, (2) clarification on data subject rights workflow for Atlas users — specifically how deletion requests would be handled given the fraud scoring layer, (3) retention period for Atlas-specific transaction logs vs our standard policy. Tom, item 2 would need input from your side on the technical feasibility of deletion.

Maya — on item 2: deletion of transaction records is possible in the main DB but the fraud model uses a separate data store for model inputs and that's currently not set up for per-user deletion. It's technically solvable but would need a sprint. I can flag it to the PM as a technical requirement if that helps.

VerifyFlow update: I spoke to their data protection contact. They operate under Standard Contractual Clauses (SCCs) and have a DPA in place. They've sent me their data processing exhibit. Rachel/Maya — I'll forward it to you. They also do a Schrems II transfer impact assessment annually and they shared the latest one. Looks like the transfer mechanism is in order.

Good news on VerifyFlow. We'll need to make sure the SCCs are executed before Atlas processes any live data — they need to be in place, not just agreed in principle. Sam, can you make sure we have countersigned copies?

DPIA is taking shape — Rachel and I have completed sections 1-6 of the ICO template. Outstanding items: (1) VerifyFlow countersigned DPA (Sam is handling), (2) committed remediation date for fraud model data deletion capability (Tom is handling), (3) Rachel to complete the 'necessity and proportionality' assessment for the fraud scoring component. Targeting a draft for review by end of next week.

VerifyFlow countersigned DPA received — filing it in the compliance document management system now. Rachel, should I also add this to the Atlas DPIA appendix?

Daniel has committed a sprint to building the fraud model per-user deletion capability. Timeline: 6 weeks from now, so mid-June. I've got it in writing — do you want me to forward to the compliance email or share here?

EU expansion regulatory update — I've been researching the EMI (e-money institution) route I mentioned earlier. In France and the Netherlands it's a viable option for some payment products and the authorisation timeline is 6-9 months (vs 12+ for a full PI licence). However it depends on whether our product scope fits within EMI permissions. Rachel, I think we need a product brief from Daniel's team before we can advise properly. The compliance pathway is very product-specific.

Maya — agree. Let's get that product brief requested. I'll ping the relevant PM. In the meantime, I want us to have a preliminary framework ready so that when they do share the brief we can turn around compliance guidance quickly. Sam, can you draft an EU expansion compliance assessment template — essentially a set of questions and criteria we'd apply to any proposed market entry?

FCA issued a 'Dear CEO' letter this week directed at payment firms regarding consumer duty obligations — specifically on vulnerable customer identification and fair treatment. Link: https://www.fca.org.uk/publications/multi-firm-reviews/dear-ceo-letter-consumer-duty-payments-2026. We should check our current vulnerable customer policy against this. Rachel, is this something we should add to the action plan?

Yes — add it to the action plan as a high-priority item. Consumer Duty enforcement is clearly increasing. Sam, I want to do a gap analysis against this letter against our current policies. Can you schedule that as a priority task for May? Put it above the operational resilience work for now.

Atlas DPIA draft is complete — sending to Rachel and Maya for final review. Key findings: data flows documented, VerifyFlow DPA in place, one open remediation item (fraud model deletion by June 13th), necessity and proportionality assessed. Identified 2 additional mitigations Rachel added around access controls — those are flagged as recommendations in the risk register. Overall assessment: the processing can proceed with the documented mitigations in place.

Understood Rachel — we won't proceed with live data until you give the all-clear. Thanks to you, Maya and Sam for pushing through this properly. I know it created friction but it's the right thing.

EU expansion compliance assessment template draft is done — sharing with Rachel and Maya. It covers: (1) product scope definition and applicable payment types, (2) licensing pathway analysis (PI vs EMI vs agent), (3) AML/CTF local requirements checklist, (4) GDPR and local data protection alignment, (5) consumer protection obligations, (6) estimated timeline and cost indicators, (7) key regulatory contacts per market. Let me know if I've missed anything.

Sam — this is excellent. One addition I'd suggest: a section on ongoing reporting obligations in each market (regulatory returns, incident reporting timelines). These vary a lot and often catch firms off guard post-authorisation. Other than that, very comprehensive.

James has acknowledged receipt of the Atlas DPIA. I've given the go-ahead to Tom and the Atlas team — they can proceed with live data onboarding. Just want to make sure that is formally noted here. The open remediation item (fraud model deletion by June 13th) remains on our tracking list.

Starting the Consumer Duty gap analysis today. Initial structure: I'll map FCA's 4 Consumer Duty outcomes (products & services, price & value, consumer understanding, consumer support) against our current policies and identify gaps. Rachel, do you want me to include customer journey mapping in scope or just policy-level analysis for now?

Regulatory update — Bank of England published a discussion paper on the future of payment regulation post-PSR review: https://www.bankofengland.co.uk/discussion-paper/2026/future-payments-regulation. It's a long read but the section on enhanced AML requirements for faster payments is relevant for us. Nothing actionable yet but I'd flag it for awareness.

Thanks Maya. I'll add it to the regulatory horizon-scanning log. Sam — also worth noting that the faster payments AML angle may be relevant when we revisit transaction monitoring thresholds in Q3. Keep a note of it.

Quick check-in on outstanding action plan items as of this week: (1) Consumer Duty gap analysis — in progress, targeting draft by May 19th, (2) EU expansion compliance assessment template — complete, ready for product team, (3) Data retention automation — with Priya for engineering scoping, (4) Atlas DPIA open item (fraud model deletion) — remediation due June 13th, (5) APP fraud reimbursement legal analysis — Maya is completing, (6) Operational resilience gap analysis — queued for Q2/Q3. Nothing critical red at the moment but Consumer Duty is the one I'm watching most closely.

Update on data retention automation scoping: engineering has estimated 6-8 weeks to build. The legal hold feature is the main complexity. We're planning to start in the next sprint cycle — provisionally kick-off May 19th. Rachel/Sam, I'll need someone from compliance available for requirements clarification during the build. Is Sam the right contact?

APP fraud reimbursement legal analysis is complete — sharing with Rachel now. Summary: our current dispute process has a 7-10 day resolution timeline vs the PSR's proposed 5-day requirement. We'd need to: (a) restructure the triage process, (b) introduce automated acknowledgement of fraud claims within 24 hours, (c) update T&Cs and customer comms, (d) implement a provisional reimbursement mechanism for confirmed APP fraud. This will need a significant ops and product effort. I recommend we schedule a cross-functional meeting sooner rather than later.

Maya — this is really clear and well-structured. I'll brief James on this week and request a cross-functional meeting. The PSR implementation timeline means this will need to be a product priority in Q3 at the latest. Sam, please add Maya's analysis to the formal compliance risk register as a high-priority regulatory change item.

Done — APP fraud reimbursement item added to the risk register. I've also updated the action plan. Rachel, just want to make sure I have the right framing: should this be a 'regulatory change' item or a 'compliance gap' item? The distinction matters for how James and the board see it at the next risk committee.

Also noting for the record — there's a Law Commission report out this week on digital assets and property rights that has some longer-term implications for crypto-linked payment products: https://lawcom.gov.uk/project/digital-assets/. Not immediately relevant to our current product set but worth flagging for horizon scanning.

Thanks Maya — I'll add it to the horizon scanning log. Our current product set doesn't include crypto but given industry direction it's worth monitoring. If product ever comes to us with a proposal in that space I want us to have some context already.

Consumer Duty gap analysis — first section done (products and services outcome). Key finding: our product disclosure documents are compliant with the letter of the requirement but the FCA's new guidance emphasises 'genuine understanding' not just disclosure. Our standard onboarding flow may not meet that bar for complex fee structures. I'm flagging this as an amber-risk item. Rachel, do you want me to circulate the first section now or wait until the full draft is ready?