Inscribe built an agentic AI system on Amazon Bedrock that detects tampered, fabricated, and AI-generated financial documents in under 90 seconds. The system reasons across multiple documents like a fraud analyst, comparing bank statements against tax forms and identity documents in a structured sequence. It delivers a 20x speed improvement over manual review while maintaining the explainability and audit trails required by financial services regulations.
This is not a simple classification model. It is an orchestration layer that chains reasoning steps, maintains evidence lineage, and surfaces confidence scores through APIs that underwriting systems can consume.
The Fraud Detection Problem
Financial institutions process thousands of loan applications daily. Each application includes bank statements, pay stubs, tax documents, and identification. A human fraud analyst spends 30 minutes per application verifying authenticity, cross-referencing information, and checking for manipulation.
Fraud now appears in 1 of every 16 documents. AI-generated forgeries grew 5x from April to December 2025. Manual review cannot scale, and rule-based systems miss evolving tactics like deepfakes and coordinated fraud rings.
The challenge is not just speed. The system must catch sophisticated forgeries while producing explanations that satisfy regulators and underwriters.
Agentic Architecture
Inscribe’s system uses Amazon Bedrock to orchestrate multi-document reasoning. The agent does not classify documents in isolation. It performs a sequence of analysis steps that mirror how a fraud analyst works:
- Document ingestion: Extract text, images, and metadata from each submitted document.
- Cross-document comparison: Compare bank statement balances against tax return income, verify employer names match across pay stubs and tax forms, check identity document photos against selfie uploads.
- Anomaly detection: Flag inconsistencies like mismatched fonts, altered transaction histories, or AI-generated signatures.
- Evidence chain construction: Build a structured record of findings with references to specific document sections.
- Confidence scoring: Assign risk scores based on the weight of evidence across all documents.
Each step produces intermediate outputs that feed into the next step. The agent maintains state across the entire analysis session, not just within individual document checks.
Orchestration Flow
The system uses Amazon Bedrock’s foundation models to perform reasoning at each step. The orchestration layer coordinates model calls, manages context windows, and enforces sequencing constraints.
class FraudDetectionAgent:
def __init__(self, bedrock_client):
self.bedrock = bedrock_client
self.evidence_chain = []
def analyze_application(self, documents):
# Step 1: Extract structured data from each document
extracted_data = {}
for doc_type, doc_content in documents.items():
extracted_data[doc_type] = self.extract_fields(doc_content)
# Step 2: Cross-reference data across documents
inconsistencies = self.cross_reference(extracted_data)
# Step 3: Analyze each document for tampering
tampering_signals = {}
for doc_type, doc_content in documents.items():
tampering_signals[doc_type] = self.detect_tampering(doc_content)
# Step 4: Build evidence chain
self.build_evidence_chain(inconsistencies, tampering_signals)
# Step 5: Generate final verdict with confidence score
return self.generate_verdict()
def cross_reference(self, extracted_data):
prompt = f"""
Compare the following financial data extracted from multiple documents.
Identify inconsistencies that indicate fraud.
Bank Statement: {extracted_data['bank_statement']}
Tax Return: {extracted_data['tax_return']}
Pay Stub: {extracted_data['pay_stub']}
Return structured JSON with inconsistencies and severity.
"""
response = self.bedrock.invoke_model(
modelId='anthropic.claude-3-sonnet',
body={'prompt': prompt, 'max_tokens': 2000}
)
return json.loads(response['body'])The orchestration layer handles retries, manages token budgets across multiple model calls, and ensures that evidence from earlier steps is available to later steps.
Audit Trail and Explainability
Financial services regulations require explainable decisions. The system cannot return a binary fraud/no-fraud verdict. It must show which documents triggered which flags and how those flags combined to produce the final risk score.
Inscribe’s agent maintains a structured evidence chain throughout the analysis. Each finding includes:
- Document reference: Which document triggered the flag (bank statement page 2, tax form line 14).
- Finding type: Tampering signal, cross-document inconsistency, or anomaly.
- Confidence score: How certain the model is about this specific finding.
- Supporting evidence: Text snippets, image regions, or metadata that support the finding.
The final API response includes the complete evidence chain, not just the top-level verdict. Underwriting systems can display this chain to human reviewers or log it for regulatory audits.
{
"application_id": "app_12345",
"verdict": "high_risk",
"confidence": 0.87,
"processing_time_seconds": 89,
"evidence_chain": [
{
"finding_id": "f_001",
"type": "cross_document_inconsistency",
"severity": "high",
"description": "Bank statement shows employer 'Acme Corp' but pay stub shows 'Acme Industries LLC'",
"documents": ["bank_statement", "pay_stub"],
"confidence": 0.92
},
{
"finding_id": "f_002",
"type": "tampering_signal",
"severity": "medium",
"description": "Font inconsistency detected in transaction history section",
"documents": ["bank_statement"],
"page": 2,
"confidence": 0.78
}
]
}State Management and Context Windows
The agent must maintain context across multiple documents and reasoning steps. A typical loan application includes 10-20 pages of documents. The agent cannot fit all content into a single model call.
Inscribe uses a state management layer that:
- Chunks documents: Splits large documents into sections that fit within model context windows.
- Maintains working memory: Stores extracted data and intermediate findings in a structured format.
- Prioritizes context: Passes only relevant prior findings to each reasoning step, not the entire history.
The orchestration layer decides which prior findings are relevant to each new analysis step. When checking a pay stub for tampering, the agent does not need to see findings from the identity document check. But when performing cross-document comparison, it needs access to all extracted data.
Deployment Shape
The system runs on AWS infrastructure with the following components:
- Amazon Bedrock: Hosts the foundation models used for reasoning and analysis.
- Amazon S3: Stores uploaded documents and intermediate analysis artifacts.
- AWS Lambda: Runs the orchestration logic and state management code.
- Amazon DynamoDB: Stores evidence chains and analysis results for audit trails.
- Amazon API Gateway: Exposes the fraud detection API to underwriting systems.
The architecture is serverless. Each application analysis runs as an independent Lambda invocation. This allows the system to scale to thousands of concurrent applications without managing infrastructure.
Performance and Failure Modes
The system completes fraud analysis in under 90 seconds for a typical loan application with 10-15 documents. This is a 20x improvement over the 30-minute manual review process.
Likely failure modes include:
| Failure Mode | Impact | Mitigation |
|---|---|---|
| Model hallucination | False positive fraud flags | Require multiple corroborating signals before flagging high-risk findings |
| Context window overflow | Incomplete analysis of large document sets | Chunk documents and prioritize high-risk sections for detailed analysis |
| Inconsistent cross-document references | Missed fraud signals | Normalize entity names and dates before comparison |
| API rate limits | Delayed analysis during traffic spikes | Implement exponential backoff and queue management |
| Ambiguous document quality | Low confidence scores | Surface uncertainty to human reviewers instead of forcing a verdict |
The system does not attempt to handle every edge case automatically. When confidence scores fall below thresholds, it escalates to human review with the partial evidence chain it has built.
Security Boundaries
Financial documents contain sensitive personal information. The system enforces several security boundaries:
- Encryption at rest: All documents in S3 are encrypted with AWS KMS.
- Encryption in transit: All API calls use TLS 1.3.
- Access controls: IAM policies restrict which services can invoke Bedrock models and access DynamoDB tables.
- Data retention: Documents and analysis results are automatically deleted after the regulatory retention period expires.
- Model isolation: Each customer’s analysis runs in an isolated execution context with no shared state.
The system does not fine-tune foundation models on customer data. All reasoning happens through prompt engineering and in-context learning. This avoids the risk of data leakage between customers.
Observability
The orchestration layer emits structured logs at each reasoning step. These logs include:
- Step name: Which analysis step is executing.
- Input size: How many tokens or documents are being processed.
- Model call duration: How long each Bedrock invocation takes.
- Confidence scores: Intermediate and final confidence values.
- Error conditions: Any retries, timeouts, or fallback logic triggered.
These logs feed into CloudWatch for monitoring and alerting. Inscribe tracks:
- P50/P95/P99 latency: How long applications take to analyze.
- Confidence score distribution: Whether the system is producing useful verdicts or too many uncertain results.
- False positive rate: How often high-risk verdicts are overturned by human review.
- Model error rate: How often Bedrock calls fail or time out.
Technical Verdict
Use this approach when you need to reason across multiple documents with regulatory explainability requirements. The agentic orchestration pattern works well for financial services, insurance underwriting, and compliance workflows where decisions must be auditable.
Avoid this approach if you need sub-second response times or if your documents are highly standardized. Simple classification models are faster and cheaper when you do not need cross-document reasoning. Also avoid if you cannot tolerate occasional false positives. The system prioritizes catching fraud over minimizing false alarms.
The 90-second analysis time is acceptable for loan underwriting but too slow for real-time payment fraud detection. The architecture is also overkill for single-document verification tasks like ID checks at account opening.