AI Prompting for Real Banking Systems

Introduction: APIs as the Backbone of Banking Systems 

APIs define how banking systems communicate. They connect channels, orchestrate workflows, and expose domain capabilities such as payments, onboarding, and account management. Designing APIs in this context requires precision. Contracts must remain stable, domain-aligned, and backward compatible. A poorly designed API introduces long-term constraints that are difficult to correct. 

Large language models introduce a new capability. They assist developers in designing APIs faster, generating contracts, and exploring design alternatives. The challenge is guiding these models to produce consistent, domain-driven, and production-ready APIs. 

From Prompt to API Contract 

Using LLMs for API design begins with a prompt. The quality of that prompt determines the quality of the resulting contract. A generic prompt such as: 

“Generate a REST API for payments” 

produces generic results. 

A structured prompt provides: domain context, business rules, constraints on behavior, expectations for consistency.

For example: 

“Design a REST API for payment initiation in a banking system. 

Requirements: 

align with a Payments bounded context  

ensure idempotent operations  

support asynchronous processing  

include clear error handling  

follow REST conventions for resource naming”  

This level of detail produces APIs that reflect real system requirements. 

Aligning APIs with Domain-Driven Design 

APIs should reflect domain boundaries, not technical layers. LLMs can assist in aligning APIs with Domain-Driven Design by: 

• generating endpoints based on bounded contexts  
• defining resources that match domain entities  
• enforcing consistent naming conventions  

For example, instead of generic endpoints such as: 

 1 /processTransaction 
 2 
 3 a domain-aligned API would use: 
 4 
 5 /payments 
 6 /payments/{paymentId} 

Prompting should explicitly require domain alignment: 

“Ensure endpoints reflect domain entities and avoid generic operation-based naming.” 

This ensures that APIs remain consistent with the underlying domain model. 

Generating OpenAPI Specifications 

LLMs can generate OpenAPI specifications that define API contracts in a structured and standardized format. A well-defined prompt can produce: endpoint definitions, request and response schemas, validation rules, error responses.

Example prompt: 

“Generate an OpenAPI 3.0 specification for a payment API with: 

POST /payments  

GET /payments/{id}  

validation for amount and currency 

structured error responses  

idempotency support”  

The resulting specification can serve as a starting point for implementation and documentation. 

OpenAPI becomes the contract between teams, ensuring that all consumers understand how to interact with the API. 

Designing for Versioning and Evolution 

Banking APIs evolve over time. New features are introduced, and existing behavior must remain stable. 

Prompting can guide LLMs to design APIs with versioning strategies: 

• URL-based versioning (/v1/payments)  
• header-based versioning  
• backward-compatible schema changes  

Example prompt: 

“Design the API to support backward compatibility. 

avoid breaking changes  

allow optional fields for extensions  

define versioning strategy”  

This ensures that APIs can evolve without disrupting existing consumers. 

Enforcing Backward Compatibility 

Backward compatibility is critical in banking systems, where multiple clients depend on stable contracts. Prompt patterns can enforce this requirement: 

“Do not remove existing fields”  

“Add new fields as optional”  

“Maintain consistent response structures”  

These instructions guide the model to produce contracts that support safe evolution. Developers should validate generated APIs against compatibility rules before adoption. 

Prompt Patterns for Consistent API Design 

Reusable prompt patterns improve consistency across teams. Examples include: 

Domain alignment pattern 

“Align endpoints with bounded contexts and domain entities.”  

Contract completeness pattern 

“Include request validation, error handling, and response schemas.”  

Evolution pattern 

“Design for backward compatibility and versioning.”  

These patterns embed best practices into prompts, reducing variability in generated outputs. 

Validating Generated API Contracts 

AI-generated API designs must be validated before production use. Validation includes: reviewing domain alignment, verifying schema correctness, testing compatibility with existing systems.

Developers should treat generated contracts as drafts, refining them through iteration. Integration tests and contract testing ensure that APIs behave as expected. 

Integrating Prompting into API Design Workflows 

Prompting fits naturally into API design workflows. Teams can use LLMs to: generate initial API drafts, explore alternative designs, produce documentation. The process typically involves: 

• defining a structured prompt  
• generating an API specification  
• reviewing and refining the output  
• validating against domain and technical requirements  

This approach accelerates design while maintaining control over outcomes. 

Balancing Automation and Control 

LLMs provide speed and flexibility. Banking systems require precision and control. The balance lies in: using prompts to guide design, 

validating outputs rigorously, maintaining ownership of final decisions. Developers remain responsible for ensuring that APIs meet production standards. 

Conclusion: Prompting as a Tool for API Design 

AI prompting introduces a new way to design APIs in banking systems. It accelerates the creation of contracts and supports exploration of design options. By structuring prompts around domain models, enforcing consistency, and validating outputs, backend developers can use LLMs effectively while maintaining control over critical system interfaces. 

In this context, prompts become part of the design process, shaping how APIs evolve and ensuring that they remain aligned with both business and technical requirements.