AI Engineering for FinTech: Architecture, Delivery and Production Controls

An AI prototype can answer a question or suggest an action. Putting that capability into a financial product raises harder questions: which data can it use, what may it do, who approves the result, and what happens when a request fails halfway through?

AI engineering for FinTech turns model capabilities into applications that teams can test, operate, and maintain. The model interprets requests and generates responses; the surrounding software retrieves information, checks permissions, and records what happened.

In this article, SDK.finance focuses on engineering applications built around large language models (LLMs), from data and retrieval to tool integrations, production controls, deployment, and ongoing support.

Choose your first AI workflow

Start with a task that has a clear user, accessible evidence, and a result the team can check. The following examples show how the workflow determines the data and permissions an application needs.

• Documentation assistant. Answer product questions from approved guides and API documentation, with source links. It needs a maintained knowledge base, but no live account access. It should recognise when the evidence is insufficient.
• Read-only payment investigation. Explain a failed payment using procedures and authorised status lookups. It needs current operational records and user permissions. It can suggest a next step but cannot change the payment.
• Action proposal for approval. Prepare a refund request with the transaction, amount, and supporting evidence for a reviewer. Any later submission needs a separately authorised execution path, with checks tied to the approved parameters.

Choose the simplest workflow that solves the user’s problem. Use documentation when an answer is enough, and connect operational records only when the task requires them.

For broader scenario selection, the guide to agentic banking use cases compares customer-facing and operational tasks, including the data access and oversight each needs.

Define the workflow and its limits

With the task chosen, write a short specification for product, engineering, and operations teams. Name the user, trigger, allowed inputs, expected output, and system responsible for the records. Describe what happens when information is missing, conflicting, or outside the user’s permissions.

Choose the simplest implementation that meets the task. A calculation with known rules belongs in ordinary application code. A documentation question may need retrieval and a single model call. A repeatable investigation may suit a predefined workflow, while a less predictable task may justify an agent that selects its next tool.

Anthropic’s guidance on building effective agents distinguishes predefined workflows from agents that choose their own steps. Use that distinction to decide where the application needs flexibility and where a fixed sequence is sufficient.

Before development, agree on stop conditions: insufficient evidence, unavailable dependencies, expired approval, exceeded time or cost budget, and requests outside scope. Specify whether the system should ask for clarification, hand over to a person, or end the task.

Define success before building

Measure the current process on a representative sample, then agree what the AI-assisted workflow must improve. Use four measures:

• Time to a verified result. Include review and correction, not just the time to the first response.
• Correction rate. Track the share of results that need rework before they meet the agreed standard.
• Handover rate. Record how often and why a person takes over. Escalating an unsupported request may be the correct outcome.
• Cost per accepted task. Include failed attempts and human review, so a low model-call price does not hide extra work.

Set targets with product and operations owners before the pilot. Compare equivalent tasks, and require quality and access checks to pass before release.

Design the architecture around data, tools, and state

The workflow specification defines what the application must do. The architecture connects the components that make it work: retrieval supplies evidence, tools provide access to approved operations, and stored workflow state allows interrupted work to resume. Keep this AI layer separate from the systems that own financial records and execute transactions. Those systems must enforce permissions and business rules independently of the model.

Data sources and retrieval

Retrieval-augmented generation (RAG) supplies relevant source material to a model before it answers. Design the retrieval process around four requirements:

• Source ownership and freshness. Record who owns each source, which versions apply, and how updates or deletions reach the index.
• Useful context. Keep API parameters with their operations and schemas, and fee rules with their applicable products and conditions. Searchable fragments must preserve these relationships.
• Access boundaries. Check permissions before material reaches the model. A relevant document may still be unavailable to the current user.
• Missing or conflicting evidence. Define when to show a limitation, request clarification, or stop rather than combine incompatible information.

Test retrieval separately from answer generation: can it find the right evidence, retain the source and version, and recognise unsupported questions? These checks help distinguish a data problem from a model problem.

Tools and execution boundaries

A tool lets the AI workflow request an operation, such as looking up a payment status. Document its accepted inputs, returned fields, permissions, errors, and any changes it can make.

Give each tool only the access it needs. Validate inputs in code, check the user’s permissions, and enforce business rules in the backend. A model-generated field called “approved” is not proof of approval.

Report success only when the responsible system confirms it. After a timeout, check the operation’s status before retrying: the request may have succeeded even though the response was lost.

Workflow state and recovery

Keep three kinds of state distinct:

• Conversation history records the exchange with the user.
• Workflow state records progress, such as evidence retrieved, approval pending, or execution requested.
• Transaction state belongs to the financial system responsible for the operation.

Save enough workflow state to resume after a restart without repeating completed actions. Define which failures are safe to retry, how long to wait between attempts, and when to stop or escalate. Where supported, use a stable operation ID and idempotency controls so repeated requests do not produce duplicate effects.

Recovery must resolve the outcome in the external system. Restarting the AI workflow does not cancel a request that a provider has already accepted. If the outcome remains unknown, keep it marked as unresolved and hand it over for investigation before attempting the action again.

Evaluation and observability

Evaluation checks results on representative tasks. Observability shows what happened during an actual run, so the team can investigate failures.

Log source and component versions, tool calls, validation results, timing, and final status. Use a shared request ID to connect the workflow with downstream operations. Restrict access to logs, set retention periods, and minimise sensitive content.

Define deliverables and owners

Turn each part of the architecture into a deliverable the team can estimate, test, and hand over. The table maps these outputs to owners and acceptance checks. Smaller teams may combine roles.

Agree how in-house teams, systems integrators, and technology providers will hand over work and provide ongoing support.

Test the data and hardest integration early. Complete one workflow, including its failure path, before adding more tasks. The results give the team a firmer basis for estimating the remaining work.

Set production controls before deployment

For each failure risk, define the control, where it runs, and a test that proves it works. The following checks address misleading source content, invalid approvals, and failures during execution.

Protect access and treat retrieved content as data

Documents and tool responses can contain text that tries to redirect the model. This is known as prompt injection. OWASP notes that retrieval-augmented generation does not fully mitigate it. Treat external content as evidence to inspect, and keep its instructions separate from the application’s governing instructions.

Limit each workflow to approved tools, data, and destinations. Enforce these restrictions in the services that receive its requests. Test attempts to retrieve another customer’s records or call an unavailable tool. These controls must still hold if malicious content misleads the model.

Bind approval to the actual action

When human approval is required, show the proposed action in a form the reviewer can assess: operation, amount, currency, destination, and relevant evidence. Store approval against those exact parameters, the reviewer, and an expiry condition.

Recheck permissions and applicable business conditions before execution. A change to the recipient or amount should invalidate the earlier approval. The workflow must also handle rejection and expired approval explicitly, rather than leaving a request waiting indefinitely.

For a payment-specific example, the guide to agentic payments follows the process from spending permission through execution, status tracking, and reconciliation.

Test failures as carefully as successful answers

Build an evaluation set from expected user tasks and realistic exceptions. Include ambiguous questions, outdated sources, missing permissions, malformed tool arguments, provider timeouts, duplicate requests, and unsupported actions.

Check retrieval relevance, factual support, and tool-call correctness to locate failures. Review high-impact errors separately; an acceptable average score can hide them.

Set release thresholds for each workflow. A documentation answer and a payment instruction need different acceptance checks. Rerun relevant tests whenever prompts, models, retrieval settings, or tool contracts change.

Choose the model and deployment approach

Use the evaluation set to compare candidate models with the same sources and tool permissions. Check answer quality, valid tool requests, response time under load, and cost. General benchmarks may not reflect performance on your product terminology or tasks.

Compare hosting options by how much your team needs to control and operate:

• Hosted model API. The provider operates the model-serving infrastructure. Your team owns the application, integrations, evaluation, and provider configuration.
• Self-hosting. Your team controls the model and serving environment, and takes responsibility for capacity, scaling, patching, availability, and model updates.
• Managed hosting. The service takes on part of the infrastructure work, while your team retains more deployment choices. The division of responsibilities depends on the service.

AWS’s inference guidance illustrates these different levels of operational ownership. For each option, check where requests are processed, how inputs and outputs are retained, whether they may be used for training, and which contractual controls apply.

Estimate the full operating cost, including model usage or compute, retrieval, storage, monitoring, retries, and human review. Test expected traffic and longer requests. Record the chosen option, its data-handling constraints, and its operational owner before the pilot.

Plan rollout, monitoring, and ongoing support

Release in stages

Once the model, hosting, and controls are ready, introduce the application in stages:

• Test environment. Verify the full workflow and its failure paths before exposing it to users.
• Shadow mode, where appropriate. Generate recommendations for comparison without allowing them to trigger actions.
• Restricted pilot. Limit users and tasks, review results against the agreed targets, and expand only when the evidence supports it.

Monitor and maintain the service

Assign owners to four recurring tasks:

• Release records. Version code, prompts, model configuration, tool definitions, and retrieval settings together. Record the knowledge-index version where feasible.
• Operating limits. Cap request duration, tool calls, retries, and model spend. Decide which tasks can use a simpler fallback and which must stop when a dependency is unavailable. Test every fallback, including a switch to another model or provider.
• Quality monitoring. Track ingestion failures, unsupported answers, tool errors, handovers, completion rates, latency, and cost. Review outputs under the applicable data-access rules. A service can remain available while returning poor answers because its sources have stopped updating.
• Maintenance. Budget for source updates, evaluation changes, dependencies, support, and user feedback. This is part of LLMOps, the ongoing operation of applications built around large language models.

Prepare for incidents

Write an incident runbook that explains how to disable a tool, pause automation, inspect unfinished workflows, and contact the integration owner. Route AI failures and payment or accounting incidents to the appropriate teams.

Rollback restores a previous application version. It does not reverse a completed payment or remove its accounting effect. Financial recovery requires checking the actual operation status and following the authorised correction or reversal process.

How SDK.finance supports AI agent workflows

When an AI agent workflow involves financial operations, it needs systems that execute authorised requests and keep reliable records. SDK.finance can provide this foundation through two complementary layers:

• Transaction Platform. Accounts, ewallets, transaction workflows, fees, and limits give an AI-enabled application a financial operating layer to connect to through APIs. The integration must define which operations the agent can request and how permissions, validation, and recovery are enforced.
• General Ledger. Double-entry records capture the accounting effects of business events under the configured accounting model. This provides a financial record beyond the agent’s conversation and workflow history. The ledger can also sit alongside an existing transaction core.

Consider a refund workflow as an integration example. An agent could gather the original transaction details and prepare a proposal for an operations employee. After approval, a separately authorised service would submit a supported operation and track its result. Where the General Ledger is used, the resulting business event would be mapped to debit and credit entries through the configured accounting rules. The proposal, approval, transaction status, and accounting entry each serve a different purpose.

The implementation team decides which APIs to expose, how to link these records, and when unresolved cases go to operations. A business that already has a transaction core can retain it and assess the General Ledger for the accounting layer. The required software and integration work follow the workflow and the systems already in place.

SDK.finance’s Product Assistant provides a concrete engineering case for the AI layer. It uses product documentation, the OpenAPI specification, and video transcripts to explain features and help users find relevant API operations. The initial low-code prototype exposed problems with generic ingestion: API fields could become separated from the operations they described, leaving retrieval with incomplete context. The team moved to a custom pipeline and addressed three areas:

• Preserve source context. Source-aware parsing keeps API operations with their request bodies and schemas, so retrieval returns information that can answer the question.
• Check evidence before generation. Retrieval uses both the user’s wording and product terminology. If the evidence is insufficient, the answer model is not called.
• Validate and trace the result. Code checks API references, removes unsupported links, and traces the stages involved in producing an answer.

The Product Assistant MCP server extends this knowledge access to compatible AI tools and custom agents. A developer can retrieve an API description, inspect its parameters, and request an answer checked against the product sources while planning an integration. The server exposes product documentation, not live account data, and does not execute platform operations. This makes it useful during development without granting an agent authority over a financial installation.

Plan your next FinTech AI integration

To scope the next milestone, bring together the workflow specification, evaluation results, and ownership map. Use the pilot’s unresolved issues to prioritise the remaining integration work.

If the workflow also needs transaction processing or an accounting layer, explore the SDK.finance Transaction Platform and General Ledger described above. Map the required interfaces and financial records to your existing systems, then define the integration work around them.