← Back to blog
AIFintechAWS BedrockMicroservicesTechnical Leadership

How I Structured AI Agentization in a Regulated Fintech

By Ronald Castillo·

When I took over as Technical Lead of LIGO’s B2C Tribe, I found myself facing a platform of 40+ microservices running on AWS EKS, with teams distributed across three squads and the regulatory pressure of Peru’s central bank (BCRP) weighing on every architectural decision. The mandate was clear: incorporate AI in a real way, not as window dressing.

The Problem with AI in Regulated Environments

Most articles about AI assume you can freely call any external API. In regulated fintech, that’s simply not the case. Every piece of data that leaves your VPC is a risk vector. Every external model that touches user information needs to go through a data impact analysis and, depending on the type of information, a compliance review.

This automatically rules out the most popular “connect ChatGPT to your app” solutions. The stack has to live within your perimeter or in a service with clear contractual guarantees.

The Decision: AWS Bedrock as the Base Platform

I chose Bedrock for three non-negotiable reasons in fintech:

  1. Data residency in region: Models in Bedrock can execute without your prompts leaving us-east-1 or us-east-2. Invocation training data isn’t used to improve foundation models.
  2. Native IAM integration: You can control which microservice can invoke which model with granular IAM policies — the same way you already work with S3 or DynamoDB.
  3. CloudTrail auditing: Every invocation is logged. For a regulator, this is the difference between “we use AI” and “we use AI and we can prove it.”

Architecture: Three Layers of Agentization

The roadmap I designed has three progressive layers:

Layer 1 — Internal Task Automation (in production)

The first agent I deployed was agente principal de operaciones, running in NestJS as part of TSL’s AgentCore. Its job: automatically review pull requests, run code quality analysis, and track epics in Jira.

Starting here was strategic: regulatory risk is minimal (internal code, not customer data) but the productivity impact is immediate. The squads recovered between 40 and 60 minutes per PR by eliminating manual review cycles for repeatable checks.

The agent works like this:

  • GitHub webhook triggers a job in NestJS
  • The job builds context: PR diff, ticket history, team standards
  • Bedrock Claude analyzes and returns structured observations in JSON
  • The agent comments on the PR and updates the Jira ticket
// Simplified flow example
async function reviewPullRequest(prContext: PrContext): Promise<ReviewResult> {
  const prompt = buildReviewPrompt(prContext);
  
  const response = await bedrockClient.invokeModel({
    modelId: 'us.anthropic.claude-sonnet-4-5-20250929-v1:0',
    body: JSON.stringify({
      messages: [{ role: 'user', content: prompt }],
      max_tokens: 4096,
    }),
  });
  
  return parseStructuredReview(response.body);
}

Layer 2 — Document Processing (in staging)

The second layer targets automating ingestion of regulatory documents and financial receipts using Bedrock with vision. The use case: a user uploads a photo of a receipt, the model extracts amount, date, merchant, and category, and persists them in DynamoDB.

The technical challenge here isn’t the extraction itself (Bedrock handles it well), it’s the post-extraction validation. In fintech, a poorly extracted transaction can impact the user’s balance. We designed a three-step validation pipeline:

  1. Extraction by Bedrock (Claude Vision)
  2. Range and consistency validation in Lambda
  3. Explicit user confirmation in the app

Layer 3 — Amazon Q Business for Internal Teams (on roadmap)

The final goal is to give squads a natural language interface over internal technical documentation: ADRs, runbooks, incident playbooks. Amazon Q Business indexes those documents (stored in S3) and allows any engineer to ask “what’s the rollback procedure for the wallet service?” without searching through Confluence.

Managing Regulatory Risk

The BCRP has clear expectations about the use of emerging technologies in critical infrastructure. The framework we use:

  • Data classification before each AI integration: Does the prompt contain personal data? Financial data? Only technical metadata?
  • Sandboxing by environment: Production agents only have access to the minimum necessary data. Dev can experiment more freely.
  • Circuit breakers: If the agent returns errors for more than N invocations, the service falls back to traditional deterministic behavior.

Results and Metrics

After six months of the agentization roadmap:

  • -65% in code review time for repeatable checks
  • +30% in configuration error detection speed
  • 0 regulatory incidents associated with AI usage in production

The key wasn’t the technology — it was defensive design: every agent has a fallback, every piece of data it touches is classified, and every invocation is auditable.

Conclusion

Integrating AI in regulated fintech isn’t hard because of the technology. It’s hard because of the design. If you start with low-risk use cases and build controls from day one, in 12 months you have an agentization platform that your engineers use every day and that your auditors can review with confidence.