Feature | AWS KYB Agent | Bedrock based implementation for Leverage Reference Architecture

[Alx-binbash]

Describe the Feature

Implement a KYB (Know Your Business) Agent solution using AWS Bedrock that integrates seamlessly with the Leverage Reference Architecture. This feature would provide an automated document processing and verification system for business onboarding workflows, leveraging AWS AI services for intelligent document extraction, validation, and decision-making.

Expected Behavior

The KYB Agent should:

• Automatically process business documents (PDFs, images) using AWS Bedrock Data Automation for OCR and data extraction
• Validate extracted information against business rules using a Bedrock Agent
• Integrate with external APIs for compliance screening (PEP screening, sanctions lists)
• Provide a RESTful API interface for initiating and monitoring KYB processes
• Store processed data securely in S3 buckets with proper lifecycle management
• Generate audit trails and maintain process state for compliance requirements
• Be deployable through Leverage CLI with minimal configuration

Use Case

Organizations implementing digital onboarding processes need automated KYB verification to:

• Reduce manual document review time from hours to minutes
• Ensure consistent application of business rules and compliance requirements
• Scale onboarding operations without proportionally increasing operational costs
• Maintain audit trails for regulatory compliance
• Enable rapid deployment of KYB solutions across different environments using Infrastructure as Code

Describe Ideal Solution

The ideal solution would include:

• A modular architecture with clear separation between infrastructure and application layers
• Choice of IaC implementation (CDK or Terraform/OpenTofu) based on research findings
• Pre-configured Bedrock Agent with customizable prompts for business rule validation
• Lambda functions for orchestration, API handling, and tool integrations
• S3 bucket structure following AWS best practices (versioning, MFA delete protection)
• API Gateway with authentication mechanisms (API keys or IAM-based)
• Observability features including CloudWatch logs and SNS notifications
• Dead Letter Queues for error handling and retry mechanisms
• Integration with Leverage's directory structure and conventions
• Comprehensive documentation and example configurations

Alternatives Considered

1. Standalone deployment without Leverage integration: Would miss the benefits of Leverage's conventions and tooling

Additional Context

Key technical considerations:

• Research needed to evaluate CDK vs Terraform/OpenTofu, focusing on:
  • Integration complexity with existing Leverage/OpenTofu infrastructure
  • Support for latest AWS Bedrock features
  • Maintainability and learning curve for teams
  • Ability to create reusable, parameterized components
• The solution should support multi-tenancy through proper resource naming and isolation
• Must handle various document formats and quality levels
• Should be cost-optimized for both low and high volume scenarios
• Security considerations including data encryption at rest and in transit
• Compliance with data privacy regulations (ability to anonymize/redact sensitive data)

The implementation would follow a phased approach in accordance with Leverage's best practices.

[exequielrafaela]

Next Steps and Team Priorities

Given the above, here are the concrete next steps and priorities we discussed for the team:

1. Define Success Metrics for the KYB Agent – Product Outcomes Focus. 📊
   Before jumping into full implementation, let’s define how we will measure the agent’s success for our clients. The issue’s Use Case already outlines the high-level goals (e.g. reduce manual review time from hours to minutes, scale without proportional cost increase, maintain compliance logs). Now we should translate those into measurable KPIs. For example:

   1. “average document processing time” (aim to go from ~2 hours manually to <5 minutes with the agent),
   2. “percentage of applications auto-approved without manual intervention”,
   3. “extraction accuracy or confidence above X% on critical fields”,
   4. “number of documents processed per day per analyst (throughput)”, etc.

   Establishing these targets will not only help demonstrate our value (to stakeholders and eventually in marketing the solution) but also guide technical decisions (for instance, needing Observability to track these metrics, or scaling decisions in the runtime). We will gather any available baseline numbers from current manual processes to have a comparison. Defining and agreeing on these metrics is a top priority, as it influences design (what to log, what to optimize) and will be how we judge if the Agent meets its objectives.

2. Infrastructure as Code Strategy (CDK vs Terraform) – Align IaC with Leverage.

   • In parallel, we must finalize our choice of IaC for deploying this solution. The two contenders are CDK vs Terraform/OpenTofu (as noted in the issue).
   • On the other hand, if most infrastructure is standard (API Gateway, Lambdas, S3, etc.) with just some hooks for Terraform/OpenTofu could work fine too. Key considerations remain integration with the existing Leverage Reference Architecture and team expertise. We will continue the research on this (there’s a separate session to evaluate CDK vs Terraform pros/cons). The goal is to decide on one, so we can maintain “a modular architecture with clear separation between infra and application” as the issue describes.
   • Once chosen, we’ll start writing the IaC for the baseline infrastructure: S3 buckets, API Gateway, Lambdas (if any), etc., incorporating any specific infra. This will run concurrently with agent development, so by the time the coding is done, deployment is not a bottleneck.

3. Design Refinement & Feature Implementation – Build the solution iteratively.

   • With the above decisions made, we will refine the overall design of the KYB agent system. This includes updating our architecture diagrams and docs to show how components interact.
   • We’ll ensure all expected features from the issue are accounted for in the design, such as:
     1. document ingestion via Bedrock Data Automation for OCR,
     2. the Bedrock Agent (prompt and logic for rule validation),
     3. external API integrations for compliance,
     4. result storage in S3, and
     5. a REST API for triggering the process.

   Each feature will be implemented in a phased manner: for example,

   • Phase 1 might hard-code some parts or handle fewer document types, and
   • Phase 2 will generalize and harden it (the issue suggests a phased approach per Leverage best practices).

🏗️ Key design elements to address:

• *Observability
• *Error Handling
• *Security & Compliance

We will document these design decisions in the repo (or in this issue) as we go, and get feedback early if needed.

7. Testing & Validation – Ensure it meets requirements. (probably needs it's own issue)
   • Once we have a working implementation (without AgentCore), rigorous testing is next. This includes unit tests for any Lambda functions or utility code, integration tests for the end-to-end KYB flow, and possibly simulation of various document types to validate OCR and data extraction accuracy. We should test the performance as well – e.g. process N documents concurrently to see if this solution scales as promised and that our use of memory/observability doesn’t introduce bottlenecks.
   • We’ll also validate that we indeed achieved the improvements (e.g. did we actually reduce the manual time by the expected amount? Is the output consistent and compliant with rules?). Any metric defined in step 2 should be measured during this phase. For example, we might run a batch of sample onboardings and measure how many required manual review, what was the average turnaround, etc., to verify we’re on track to deliver the promised benefits.

[exequielrafaela]

@Alx-binbash reference Terraform / OpenTofu aws official Bedrock module: https://github.com/aws-ia/terraform-aws-bedrock/tree/main to be integrated in a future iteration ✅ .

CC: @igomezraggio89 @diego-ojeda-binbash @martingaleano

[exequielrafaela]

🚀 Status Update & Pending Actions (after last discussion with @Alx-binbash )

✅ What’s already in place

• We have a working branch for the KYB Agent under the ref-architecture repo: data-science/us-east-1/bedrock-agent-kyb.
• The Bedrock-based KYB/data-automation pipeline foundation is present — data ingestion, agent skeleton, etc., is wired up.

🎯 What remains pending (per our last chat)

Area	Task / Observation
End-to-end usability / demo readiness	Make the CLI script (used in the SF demo) functional for a real E2E test — not just a proof-of-concept, but a sample customer-workflow validation.
Documentation & onboarding	Add AWS components architecture diagrams into the README of the relevant layers/modules: • data-science/us-east-1/bedrock-agent • data-science/us-east-1/bedrock-kyb-bda — this will improve clarity for future reviewers or contributors. Use diagram-as-code tools (e.g. diagrams.mingrammer.com) with Claude Code as we discussed the possibility here (https://binbashar.slack.com/archives/C07NDJULSEA/p1765305114687569?thread_ts=1764678818.113769&cid=C07NDJULSEA).
Pull Request & merge path	Finalize a PR for the KYB Agent branch, including functional CLI + updated README + architecture diagrams, so we can merge it into the ref-arch main branch.

🗓 Suggested Immediate Next Steps

1. @Alx-binbash — prepare PR for the KYB Agent branch including README updates + architecture diagrams.
2. Run an end-to-end test using the CLI script to validate the full KYB workflow (ingest → extract → validate → output).
3. Agree on folder naming / structure for clarity (e.g. bedrock-kyb-agent).
4. Once PR is ready & E2E validated — merge into main ref-arch branch, then plan ref-arch cleanup to fully embed the module.

---

✅ Why this matters

• Clarity & maintainability: Architecture diagrams help document components/data flows and make onboarding easier. This aligns with good AWS-architecture documentation practices.
• Reusable reference architecture: Merging the functional KYB Agent module into ref-arch guarantees it’s production-ready, documented and reusable — not just a one-off demo.
• Better project discipline: A clean repo structure + defined PR + documentation + E2E tests ensures we avoid stale proof-of-concept code lingering and increases team confidence when reusing modules.

CC: @diego-ojeda-binbash @igomezraggio89 @msorozabal @martingaleano