Prompting LLMs for Compliance: Translating PSD3 into Technical Requirements

A Business Analyst’s Perspective 

From Regulation to Implementation 

Regulatory frameworks such as PSD3 are designed to define principles, obligations, and expected outcomes. They are not intended to describe system behavior, API specifications, data models, or implementation workflows. One of the primary responsibilities of a Business Analyst in banking is translating regulatory language into actionable requirements that engineering teams can design, build, test, and maintain. 

With the emergence of AI-powered prompting, this translation process can be significantly accelerated. Large Language Models (LLMs) can help identify obligations, structure requirements, generate traceability artefacts, and map regulations to system behavior. The challenge is not whether to use AI, but how to use it in a way that produces accurate, traceable, auditable, and compliant outputs. 

The Gap Between Legal Language and System Design 

Regulatory texts operate at a much higher level of abstraction than technical systems. For example, PSD3 may require organizations to: 

• Ensure explicit customer consent for data access 

• Provide secure and auditable access to financial information 

While these requirements are clear in intent, they remain ambiguous from an implementation perspective. 

 

A Business Analyst must translate them into: 

• System capabilities 

• Business workflows 

• Validation rules 

• Audit mechanisms 

• Security controls 

AI prompting can support this process by structuring the interpretation of regulatory language and exposing implementation considerations that may otherwise be overlooked. 

Using Prompts to Extract Requirements 

The first step is extracting structured requirements from regulatory text. A generic prompt typically generates a summary. A well-designed prompt generates actionable outputs that can be consumed by engineering and compliance teams. 

Example prompt: 

'Extract technical requirements from the following PSD3 clause: 

- Identify system capabilities 

- Define required data flows 

- Highlight validation rules 

- List non-functional requirements such as security, resilience, and auditability' 

 

This typically results in:  

• Consent capture mechanisms 

• Authentication and authorization requirements 

• Data retention obligations 

• Logging and traceability expectations 

• Security and monitoring controls 

The key is guiding the model to separate regulatory intent from implementation details. 

Structuring Requirements for Engineering Teams 

Once extracted, requirements must be organized into a format that development teams can effectively use. Prompting can help categorize requirements into: 

• Functional requirements 

• Non-functional requirements 

• Constraints 

• Dependencies 

• Acceptance criteria 

 

For example: 

'Convert the extracted requirements into: 

- API-level requirements 

- Workflow descriptions 

- Validation rules 

- Audit requirements' 

 This produces outputs that are more closely aligned with established software development processes. In practice, clarity at this stage significantly reduces misunderstandings during implementation and testing. 

Generating Traceability Matrices 

Traceability is essential in regulated environments. Every requirement should be linked to: 

• The regulatory source 

• The system component implementing it 

• The validation mechanism or test case ensuring compliance 

LLMs can assist in generating initial traceability matrices. 

 

Example prompt:  

'Create a traceability matrix linking: 

- PSD3 clauses 

- System requirements 

- APIs or services 

- Validation mechanisms' 

 Maintaining traceability ensures that no requirement is lost, compliance can be demonstrated during audits, and implementation decisions remain transparent throughout the delivery lifecycle. 

Mapping Requirements to System Behavior 

Regulatory requirements must ultimately be translated into observable system behavior. 

 Examples include: 

• Consent → API authorization checks 

• Auditability → Logging, monitoring, and traceability 

• Data access control → Token-based permissions and access policies 

• Strong Customer Authentication → Identity verification workflows 

Prompting can support this mapping by connecting business requirements with technical implementation patterns, helping bridge the gap between analysis and engineering. 

Validating Compliance Logic 

One of the most valuable applications of prompting is validating whether a proposed solution design satisfies regulatory obligations. 

Example prompt: 

'Validate the following API design against PSD3 requirements for consent management and data access. Identify gaps, risks, and inconsistencies.' 

 

This enables Business Analysts to:  

• Review solution designs 

• Identify missing controls 

• Detect compliance gaps early 

• Improve collaboration with architects and developers 

 In practice, this step often reduces costly rework and minimizes compliance-related risks later in the project lifecycle. 

Ensuring Consistency Across Requirements 

Large regulatory frameworks contain numerous interconnected requirements. Common challenges include: 

• Similar rules implemented differently across services 

• Duplicated or conflicting requirements 

• Inconsistent interpretations between teams 

Prompting can be used as a consistency-checking mechanism. 

 

For example: 

'Ensure consent management rules are applied consistently across all APIs, workflows, and customer journeys.' 

This helps maintain alignment across products, services, and delivery teams. 

Avoiding Common Pitfalls 

AI-assisted compliance analysis introduces its own risks. Usual pitfalls include: 

• Relying on generated outputs without validation 

• Misinterpreting regulatory language 

• Generating requirements without sufficient context 

• Losing traceability between regulation and implementation 

• Treating AI-generated outputs as authoritative 

 

A Business Analyst must remain accountable for decisions and interpretations. 

 AI can support analysis, but it cannot replace domain expertise, critical thinking, and professional judgment. 

Integrating Prompting into BA Workflows 

Prompting can be incorporated into standard Business Analysis activities: 

• Extracting requirements from regulatory texts 

• Structuring requirements for engineering teams 

• Generating traceability matrices 

• Reviewing solution designs 

• Supporting compliance assessments 

Used correctly, AI becomes an accelerator rather than a replacement, improving efficiency while preserving governance and accountability. 

Prompting as a Compliance Tool 

Translating PSD3 into technical requirements is a complex process requiring precision, traceability, and deep domain knowledge. AI prompting provides a powerful mechanism for supporting this work. It helps extract requirements, structure information, identify gaps, and validate implementation approaches. 

From a Business Analyst's perspective, the value lies in improving clarity, consistency, and productivity while maintaining human oversight. In regulated banking environments, compliance is never optional. Prompting becomes a valuable tool for translating regulatory requirements into system behavior, helping ensure that systems are not only functional, but also compliant by design.