AI Prompting for Real Banking Systems

From Events to Execution 

Event-driven architecture is widely adopted in banking systems. Kafka pipelines power payments, fraud detection, reconciliation, and customer activity tracking. The benefits are clear: decoupling, scalability, and real-time processing. The challenge is not adopting Kafka. It is designing correct event flows. 

A poorly designed event stream introduces inconsistent state, duplicate processing, and hard-to-debug failures. From a backend perspective, most production issues in event-driven systems come from design flaws rather than infrastructure limitations. 

LLMs introduce a new capability: assisting developers in designing event schemas, flows, and resilience patterns. The value depends on how well prompts guide these models toward deterministic, production-safe designs. 

Prompting for Event Contracts 

Event contracts define how services communicate. They are the backbone of any Kafka-based system. A weak prompt might generate a generic event: 

“Create a Kafka event for payments” 

This produces vague, inconsistent structures. 

A structured prompt enforces clarity: 

“Design a Kafka event schema for a payment initiation event with:  

unique transaction ID 

timestamp 

amount and currency 

account identifiers 

status field 

backward-compatible structure 

no breaking changes in future versions” 

This leads to a contract such as: 

 1 { 
 2   "eventId": "uuid", 
 3   "eventType": "PaymentInitiated", 
 4   "timestamp": "ISO-8601", 
 5   "paymentId": "string", 
 6   "amount": 100.00, 
 7   "currency": "EUR", 
 8   "sourceAccount": "string", 
 9   "destinationAccount": "string", 
10   "status": "PENDING" 
11 } 

Prompting must enforce: explicit fields, clear semantics, compatibility constraints.This ensures that events remain stable as systems evolve. 

Designing Event Flows with AI 

Event-driven systems are defined not just by events, but by how they flow between services. LLMs can help model these flows when prompts include: participating services, sequence of events, expected outcomes. 

Example prompt:

“Design an event-driven payment flow using Kafka with: 

payment initiation 

fraud check 

ledger update 

notification 

Include failure handling and retries” 

This produces a flow: 

payment-initiated  -> fraud-check-service  -> fraud-score-event -> ledger-service  -> payment-confirmed -> notification-service 

The key is guiding the model to: 

• define clear transitions 
• avoid ambiguous dependencies 
• ensure that each step produces a new event 

From experience, explicit flow modeling reduces hidden coupling between services. 

Modeling Sagas Through Prompting 

Complex banking workflows require coordination across multiple services. Sagas provide a structured way to manage these flows. LLMs can assist in designing saga patterns when prompted correctly. 

Example prompt: 

“Model an orchestrated saga for loan approval with: 

KYC verification 

credit scoring 

risk assessment 

approval or rejection 

Include compensation steps” 

Resulting structure: 

START -> KYC_CHECK -> CREDIT_SCORE -> RISK_ASSESSMENT -> APPROVED 

FAILURE PATH: -> REVERT_RISK -> RELEASE_RESERVATIONS -> APPLICATION_REJECTED 

Prompting must include clear steps, compensation logic, and state transitions. This ensures that workflows remain consistent and recoverable. 

Generating Idempotency Strategies 

Duplicate events are a reality in distributed systems. Kafka guarantees at-least-once delivery, which means consumers must handle repeated messages safely. LLMs can help design idempotency strategies when guided properly. 

Example prompt: 

“Design an idempotent Kafka consumer for payment processing with: 

unique event ID 

deduplication logic 

safe retries” 

Generated approach: 

 1 if (processedEvents.contains(event.getEventId())) { 
 2     return; 
 3 } 
 4 processPayment(event); 
 5 processedEvents.add(event.getEventId()); 

Prompting should enforce: unique identifiers, persistent deduplication, deterministic processing. Without this, retry logic becomes a source of errors. 

Prompting for Retry and Failure Handling 

Failure handling defines the reliability of event-driven systems. LLMs can assist in designing retry strategies when prompts include: retry limits, backoff strategies, and dead-letter handling. 

Example prompt: 

“Design a retry strategy for Kafka consumers with: 

exponential backoff 

max retry attempts 

dead-letter queue for failures” 

This produces patterns that align with production requirements. From experience, systems that lack structured retry strategies accumulate hidden failures that surface later as data inconsistencies. 

Enforcing Consistency Through Prompts 

Event-driven systems often rely on eventual consistency. Prompting must define where consistency is required and where it can be relaxed. 

Example:“Ensure that ledger updates remain strongly consistent. Allow eventual consistency for notifications.” 

This distinction prevents incorrect assumptions in generated flows. Developers must guide the model to respect domain invariants, especially in financial operations. 

Prompt Templates for Kafka Design 

Reusable prompt templates improve consistency across teams. Examples include: 

Event schema template 

“Define schema with versioning, optional fields, and clear domain semantics.” 

Flow design template 

“Model event transitions, producers, and consumers with failure paths.” 

Resilience template 

“Include idempotency, retries, and dead-letter handling.” 

These templates embed best practices into the prompting process. 

Validating AI-Generated Designs 

LLMs assist in design, but validation remains essential. Developers must: review event schemas for correctness, test flows in controlled environments, and validate idempotency and retry behavior. Prompt outputs should be treated as drafts, refined through iteration. 

Integrating Prompting into Event-Driven Development 

Prompting becomes part of the design phase: define requirements, generate event schemas and flows, review and refine outputs, implement and validate. This accelerates design while maintaining control. 

From a backend perspective, the goal is not to automate decisions, but to structure them more effectively. 

Designing Better Event Systems with AI 

Event-driven architectures require careful design. Kafka provides the infrastructure, but correctness depends on how events, flows, and failure handling are defined. AI prompting introduces a new way to approach this design. By structuring prompts around domain rules, consistency requirements, and resilience patterns, developers can generate better starting points for complex systems. 

In banking environments, where correctness and reliability are essential, this approach supports faster design without compromising control. Prompts become part of the architecture process, shaping how systems communicate and evolve.