AWS Builder Center

Builder Center

The Fast Path, Built: A Reference Architecture for Minutes-Not-Days Bank Decisions

The Fast Path, Built: A Reference Architecture for Minutes-Not-Days Bank Decisions

The reference architecture for minutes-not-days bank decisions — parallel data pull, deterministic rules, agentic orchestration, and audit by design.

Faris Haddad - AWS

Data and Ai lead at AWS
Builds on two prior articles. This piece assumes the governance foundations from Mechanical Governance for LLM Decisions  (the defense-in-depth policy pattern) and Building GAD-P on AWS  (AgentCore Policy with Cedar). Where those articles cover the governance mechanics in depth, this one applies them to transactional lending. I link back rather than repeat.
The companion piece  to this article argued that the bottleneck in bank lending is process, not modelling — that 95% of a ten-day decision is data movement and human coordination. This piece builds the architecture that removes it.
The goal is a lending decision for amounts up to £250,000 that completes in minutes for standard cases, routes cleanly to a human for edge cases, and produces an immutable audit record either way. Everything here runs on AWS-native services, and phase one requires no custom model training.

Solution overview

An application flows through ten steps:
  1. The customer submits through a web or mobile front end (AWS Amplify ).
  2. Amazon API Gateway  validates the request and the customer's identity token.
  3. Amazon EventBridge  decouples intake from processing, so the customer gets an instant acknowledgement.
  4. Amazon Bedrock AgentCore  Harness activates the orchestration agent.
  5. AWS Step Functions  runs the data pull — Open Banking, bureau, and existing-exposure calls — in parallel.
  6. A deterministic AWS Lambda  function computes affordability.
  7. An Amazon SageMaker AI  endpoint returns a credit-risk score.
  8. A policy-rules Lambda evaluates the application against the bank's lending rules.
  9. The pipeline either auto-approves or generates a brief for a human underwriter.
  10. A Decision Token is written to AWS CloudTrail , and the customer is notified.
The rest of this article works through those steps in the order you would build them.

Prerequisites

To build along, you will need: an AWS account with access to Amazon Bedrock AgentCore and Amazon SageMaker AI; an Open Banking Account Information Services (AIS) provider account (for example TrueLayer or Yapily); a credit bureau API account; and the AWS CDK installed for infrastructure deployment. Familiarity with the two companion governance articles is assumed.

The data layer (week 1–2)

The single biggest time saving comes from replacing manual document collection with live data.
Three Lambda functions sit behind the orchestration layer: one calls an Open Banking AIS provider for twelve months of categorised transactions, one calls the credit bureau, and one queries the bank's core system for existing exposure. Step Functions runs all three as a parallel Map state, each branch with its own retry policy and timeout, so a slow bureau response cannot stall the Open Banking pull. If a branch exhausts its retries, the application is flagged for human review rather than failing outright.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
{
"Type": "Parallel",
"Branches": [
{
"StartAt": "OpenBankingPull",
"States": {
"OpenBankingPull": {
"Type": "Task",
"Resource": "arn:aws:lambda:eu-west-2:ACCOUNT:function:fn-open-banking-pull",
"Retry": [{ "ErrorEquals": ["States.ALL"], "MaxAttempts": 3, "IntervalSeconds": 5 }],
"TimeoutSeconds": 45,
"End": true
}
}
},
{
"StartAt": "BureauScore",
"States": {
"BureauScore": {
"Type": "Task",
"Resource": "arn:aws:lambda:eu-west-2:ACCOUNT:function:fn-bureau-score",
"Retry": [{ "ErrorEquals": ["States.ALL"], "MaxAttempts": 3, "IntervalSeconds": 5 }],
"TimeoutSeconds": 30,
"Catch": [{ "ErrorEquals": ["States.ALL"], "Next": "FlagForReview" }],
"End": true
}
}
}
],
"Next": "AffordabilityCalc"
}
This affordability-data pattern is not theoretical. Experian already delivers affordability verification through models served on Amazon SageMaker, which is a useful precedent to point to when a risk team asks whether real-time affordability assessment is production-grade.

Accelerating the data foundation with ADOP

Hand-writing the three data Lambdas, their quality checks, and the Silver and Gold layers that feed the credit model is exactly the "weeks of pipeline plumbing" that the Agentic Data Operations Platform (ADOP)  is designed to compress. ADOP is a reference architecture, not a managed service — specialized AI agents run in development, reason about a new source described in natural language, and generate the ETL, quality checks, semantic-layer definitions, and compliance controls across the Bronze-to-Silver-to-Gold lifecycle.
The design choice that makes ADOP a natural fit here is the same one this architecture already makes at the decision layer: agents in dev, deterministic artifacts in prod. ADOP's agents generate the pipeline code, engineers review it, and CI/CD promotes deterministic PySpark, SQL, orchestration DAGs, and — notably — IAM and Cedar policies into production. Production runs the static artifacts without a model in the loop, so the runtime stays auditable. That is the signal/decision separation from this series applied one layer down, at data onboarding.
Two things make it especially relevant for a regulated lending build:
  • Compliance moves to onboarding time. One regulation prompt per governance framework is applied as each source lands, so legal reviews a prompt file rather than application code. (You remain responsible for validating that the controls meet your regulatory obligations.)
  • One Cedar foundation, two enforcement points. ADOP generates data-access Cedar policies at build time — who and what may read or transform each dataset as it lands. The Week 4 layer covers tool-call authorisation at runtime, where the amount threshold is a static Cedar rule today and session-dependent conditions are where a temporal extension like Dogwood is heading. Both are Cedar, so there is one policy language across the stack rather than two dialects — data access when a source is onboarded, and agent actions when a decision is made. Static access rules belong in the generated build-time policies; anything that depends on what happened earlier in a session is the forward-looking, session-aware part.
ADOP complements AgentCore rather than replacing it: ADOP is the build-time accelerator, AgentCore is the runtime. The adoption curve is front-loaded — the early investment is encoding your standards into the decision engine, after which each new source is a prompt, not a project. For a bank onboarding many data sources into a lending platform, that trade pays off from the second source onward.

The rules engine (week 2–3)

Affordability is calculated by a plain Lambda function — debt-to-income ratio, net disposable income, and a stress test at an elevated rate. There is deliberately no machine learning here.
Why not just ask an LLM? Because a lending affordability figure has to be reproducible and defensible. A large language model is non-deterministic: ask it twice and you may get two answers, and neither comes with a stable, auditable derivation. The FCA's consumer credit rules require that a declined applicant receive a specific, consistent reason. A deterministic function produces exactly that — the same inputs always yield the same figure and the same policy citation. This is the whole reason the architecture separates the signal (the model's risk score) from the decision (the rules). The model informs; it does not decide.

The orchestrator (week 3–4)

Amazon Bedrock AgentCore Harness runs the orchestration loop — calling the model, selecting tools, passing results back, managing context, and handling failures — as managed infrastructure. The lesson here is simply: do not hand-roll the agent loop. Running one in production means owning compute, a sandbox, secure tool connections, memory, identity, and observability, and the Harness provides those.
Three companion capabilities matter for a regulated build:
  • AgentCore Policy with Bedrock Guardrails evaluates inputs to gateway targets and outputs from authorised actions for prompt injection, harmful content, and sensitive-data exposure. Enforcement sits at the infrastructure layer, not in the prompt, so an adversarial application field cannot talk its way past it.
  • AgentCore Optimization analyses production traces — surfacing where the agent fails, misroutes, or loops, and supporting A/B testing of instructions.
  • AgentCore Identity references existing AWS Secrets Manager ARNs, so the Open Banking and bureau credentials are injected per tool call rather than copied into function environments.

Authorisation with Cedar (week 4)

The rule "the agent may issue a decision only under the autonomous threshold, and only after the policy check has passed" should not live as an if statement buried in a Lambda. Expressed that way it is invisible to auditors and easy to bypass.
Express it instead as a policy evaluated inside the AgentCore gateway. The static part — the amount threshold — is a plain Cedar policy you can deploy today. The "only after the policy check passed this session" part is temporal: static Cedar has no notion of what happened earlier in a session. This is where Dogwood — a forward-looking temporal extension of Cedar, evaluated at the gateway with a session-aware lookback — points the way. The pattern below shows the direction of travel; the static Cedar threshold rule is deployable now, and the temporal rule illustrates where session-aware authorisation is heading. Here is the static Cedar rule:
1
2
3
4
5
6
7
8
9
10
// Static rule: anything above the autonomous threshold is forbidden,
// regardless of model confidence. Plain Cedar — no temporal condition.
forbid(
principal == Agent::"natwest-lending-agent",
action == AgentCore::Action::"issue_decision_token___invoke",
resource
)
when {
context.request.loan_amount > 250000
};
The "only after the policy check passed" condition is temporal — it depends on what happened earlier in the session — so it belongs in Dogwood, evaluated inside the gateway against the automatically maintained session trajectory:
The "only after the policy check passed" condition is temporal — it depends on what happened earlier in the session. Static Cedar can't express it directly today; Dogwood illustrates how a session-aware lookback would, evaluated at the gateway against a maintained session trajectory:
1
2
3
4
5
6
7
8
9
10
11
12
// Illustrative temporal rule (forward-looking): the decision tool may fire
// only if the policy-check tool returned PASS earlier in this session.
permit(
principal == Agent::"natwest-lending-agent",
action == AgentCore::Action::"issue_decision_token___invoke",
resource
)
when {
formerly(
context.tool == "run_policy_check" && context.result == "PASS"
) within 24h
};
A session-aware lookback would maintain the trajectory automatically, so the "only after" condition becomes enforceable rather than aspirational — no custom state store required. The operational model for adopting temporal authorisation follows a familiar shape: run in a log-only mode first, where every request passes and allow/deny decisions are logged so you can confirm the rules would not block legitimate traffic; then, once the windows are tuned, promote the highest-risk tool — the decision-token issuer — to enforce ahead of lower-risk ones. In the meantime, the static Cedar threshold rule is deployable today, and the pre-decision sequencing can be enforced in the interim by the Step Functions state machine itself (the decision state is simply unreachable until the policy-check state has passed). Dogwood shows where this consolidates into the policy layer; the architecture does not depend on it to ship. This is the same direction I set out for the governed analytics platform in Building GAD-P on AWS — the pattern generalises from natural-language analytics to lending.

The signal engine (week 4–5)

For phase one, the credit-risk score comes from a built-in Amazon SageMaker AI XGBoost model. SageMaker positions XGBoost squarely at financial-services risk use cases, and it needs no bespoke training pipeline — a strong reason to start here rather than with a custom model. Lumi's loan-approval build on SageMaker AI is a good customer reference for this stage.
Phase two is the upgrade path. SageMaker now offers serverless model customisation with full fine-tuning, which is the route to a transaction-specific model trained on the bank's own history once the pipeline is generating clean decision data.

The human loop and audit (week 5–6)

When an application does not clear the straight-through path, a Lambda uses Claude on Amazon Bedrock to generate a structured underwriter brief. The model generates the brief; it does not make the decision. The underwriter reads a clear summary and decides.
The wait is handled by a Step Functions waitForTaskToken step: the workflow pauses, the underwriter's dashboard holds the token, and submitting the decision resumes the pipeline. No polling, no custom callback service.
Every path ends at the same place — a Decision Token written to AWS CloudTrail and aggregated by AWS Audit Manager . The defense-in-depth reasoning behind treating this as the compliance backbone, rather than a log, is the subject of Mechanical Governance for LLM Decisions.

Deployment notes

A few things worth knowing before you deploy:
  • Cross-compilation. If you build on an ARM Mac and deploy to an x86_64 Lambda, functions with architecture-specific native wheels — pydantic_core is the usual culprit — fail with confusing import errors. Build against manylinux2014_x86_64, or keep those functions on the standard library.
  • Region and partition. AgentCore capabilities roll out by region and partition over time — memory, policy, and harness reached AWS GovCloud (US-West) in August 2026, for instance. Confirm availability in your target region before committing an architecture, especially for a regulated deployment.

Cleanup

If you deploy this reference architecture to experiment, tear it down to avoid ongoing charges: delete the SageMaker endpoint, remove the Step Functions state machine and Lambda functions (the CDK stack destroy handles both), delete the AgentCore Harness runtime and gateway, empty and delete the DynamoDB tables and S3 buckets, and disable the CloudTrail trail if you created a dedicated one. The Open Banking and bureau provider sandboxes should be deactivated on their respective consoles.

The reusable pattern

Nothing in this architecture is intrinsically about lending. Swap the domain tools — bureau call becomes sanctions screening, affordability calculation becomes document validation — and the same skeleton serves KYC, dispute resolution, or trade-finance checks.
That is the real payoff. The signal-decision-audit separation, Cedar-based tool authorisation, and immutable Decision Tokens together form a domain-agnostic pattern for governed automated decisions. It is the same pattern behind governed natural-language analytics; this article simply pointed it at a lending queue. Build it once and the second use case is a configuration exercise, not a new architecture.

Conclusion

A minutes-not-days lending decision is an orchestration problem with a governance backbone, and both are now standard AWS building blocks. Step Functions handles the parallel data pull, AgentCore Harness runs the agent loop, Cedar policy enforces the authorisation rules, and Decision Tokens on CloudTrail make every outcome auditable. Start with the deterministic rules and a built-in SageMaker model — no custom training — then upgrade the signal engine once the pipeline is producing clean data. The result is fast for customers, safe for regulators, and reusable across every other governed decision in the bank.

References

# data-strategy# banking# ai-assisted-workflows
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article