DEV Community: Vaibhav Shakya

One Payment, One Intent: Architecting Replay-Resistant Mobile Transactions Beyond Idempotency

Vaibhav Shakya — Thu, 05 Nov 2026 05:20:23 +0000

A payment request can be technically unique while representing a financial action the customer has already authorized.

Consider a customer transferring ₹10,000 through a mobile application. The payment processor accepts the transaction, but the response is lost. The application times out, and the customer retries.

If the retry generates a new idempotency key, the backend may treat it as an entirely new operation.

The result could be two valid transactions for one intended payment.

This exposes a critical architectural distinction: preventing duplicate API requests is not the same as preventing duplicate financial effects.

The Problem: Idempotency Is Not Business Intent

Idempotency keys help payment systems recognize repeated requests and recover previously initiated operations.

However, their guarantees depend on the provider's implementation, scope, and retention policies.

Consider two requests:

POST /payments
Idempotency-Key: pay_8f29c7

POST /payments
Idempotency-Key: pay_19d4a2

Both might pass authentication and idempotency checks.

Yet both could represent the same customer action.

An idempotency key identifies a retryable operation. A payment intent represents the financial action that operation is supposed to perform.

A reliable architecture needs to preserve this relationship across retries, application restarts, and asynchronous processing.

Where Payment Execution Gets Difficult

Several failure scenarios make request-level deduplication insufficient.

Concurrent execution: Two backend instances may attempt to execute the same authorized payment simultaneously.
Ambiguous timeouts: A processor may complete a transaction even when its response never reaches the backend.
Replayed authorization: A previously valid signed request may be submitted again without effective freshness or consumption checks.
Delayed callbacks: Duplicate or out-of-order processor notifications may trigger inconsistent state transitions or accounting effects.

These problems cannot be reliably solved by disabling the Pay button or generating unique transaction identifiers.

Architectural Direction: Make Intent Authoritative

A stronger approach is to make the backend responsible for the payment lifecycle.

The mobile application initiates the customer's intended action, but the backend controls authorization, execution eligibility, and financial state.

The essential controls include:

Persistent payment intents: Associate every payment with a stable backend-owned identifier and validated financial details.
Transaction-bound authorization: Bind approval to the amount, beneficiary, and other material payment attributes.
Atomic state transitions: Prevent concurrent execution attempts from independently claiming the same authorized intent.
Stable processor references: Recover existing processor operations instead of creating new transactions after ambiguous failures.
Durable execution and reconciliation: Use recoverable commands, appropriate uniqueness constraints, and authoritative provider evidence to resolve uncertain outcomes.

For sensitive operations, cryptographic freshness controls can provide additional replay protection.

However, signatures, nonces, device attestation, and hardware-backed keys complement the payment state machine. They do not replace backend authorization or business-level execution controls.

The Mobile Application Is Not the Financial Authority

Android Keystore and iOS Secure Enclave capabilities can help protect cryptographic operations.

But even a legitimate application instance does not automatically prove that every submitted payment represents a new customer authorization.

Mobile applications should therefore preserve existing intent identifiers, recover authoritative transaction states after interruptions, and avoid generating new financial execution identities during automatic retries.

A timeout should lead to status recovery or reconciliation, not blind payment re-execution.

The Takeaway

Reliable payment architecture is not about guaranteeing that messages travel through distributed systems exactly once.

It is about ensuring that repeated delivery, delayed responses, and application failures do not silently create additional financial effects.

One payment, one intent means execution must remain bound to a durable business authorization—not merely to an HTTP request.

Want the deeper architectural breakdown, implementation considerations, failure scenarios, and full reasoning?

Read the complete article on Medium:

One Payment, One Intent: Architecting Replay-Resistant Mobile Transactions Beyond Idempotency

Follow my work

I write about software architecture, FinTech, AI, cybersecurity, distributed systems, mobile engineering, and production engineering.

Connect with me on LinkedIn

Explore more at vaibhavshakya.com

#FinTech #PaymentSecurity #SoftwareArchitecture #DistributedSystems

When the KYC Document Is AI-Generated: Why OCR Success Does Not Mean Identity Trust

Vaibhav Shakya — Wed, 04 Nov 2026 04:38:50 +0000

When the KYC Document Is AI-Generated: Why OCR Success Does Not Mean Identity Trust

A customer uploads an identity document. OCR successfully extracts the name, date of birth, and identification number. Every field passes format validation.

But what if the entire document was AI-generated?

OCR can recognize text with high accuracy, but it cannot independently establish whether the document is genuine or whether the applicant owns the identity.

This distinction creates a critical trust boundary in digital onboarding systems.

The Architectural Problem

A conventional KYC workflow may look like this:

Document Capture → OCR → Field Validation → KYC Approval

The weakness appears when successful information extraction is treated as sufficient evidence for identity verification.

A synthetic document can contain readable text, realistic layouts, and internally consistent information while having no legitimate issuing history.

OCR success is a processing result, not an identity-trust decision.

Where It Gets Difficult

Identity verification introduces several challenges beyond extracting document fields.

Document authenticity: A readable document may be synthetic, altered, or counterfeit.
Applicant verification: Even an authentic document may be presented by someone other than its rightful holder.
Capture integrity: Forged media may be injected through manipulated camera feeds or compromised application environments.
Asynchronous verification: Delayed provider responses, duplicate callbacks, or stale evidence may incorrectly influence onboarding decisions.

Android Play Integrity and Apple App Attest can provide useful signals about the application environment, but neither proves that the submitted identity document is authentic.

Similarly, an AI-generated-image detector should not independently determine whether an identity is trustworthy.

Architectural Direction

A stronger KYC workflow separates extraction from verification:

Capture → OCR → Document Authenticity → Attribute Validation → Applicant Binding → Risk Decision

The backend should own the authoritative KYC state and enforce several principles:

OCR success must never automatically change the identity status to VERIFIED.
Verification results must be associated with the correct session and evidence version.
Missing, failed, and inconclusive checks must not silently become successful outcomes.
Approval must depend on the required verification evidence satisfying the applicable assurance policy.
Retries and asynchronous callbacks must not create unauthorized state transitions.

Consider a document that passes OCR while its authenticity verification is still pending.

The backend should preserve a non-approved state until the required evidence is available and evaluated.

If authenticity verification later fails, the earlier OCR success must not override that result.

The Takeaway

AI-generated identity documents expose an architectural weakness that predates generative AI.

Extracting identity information is not the same as establishing identity trust.

Secure onboarding depends on explicit trust boundaries, backend-controlled decisions, evidence binding, and verification policies appropriate to the financial risk.

A document can be perfectly readable and still be untrustworthy.

Want the deeper architectural breakdown, Android/iOS security considerations, backend state-management patterns, failure scenarios, and implementation trade-offs?

Read the complete article on Medium

Follow my work

I write about software architecture, FinTech, AI, cybersecurity, distributed systems, mobile engineering, and production engineering.

Connect with me on LinkedIn

Explore more at vaibhavshakya.com

#KYC #IdentityVerification #FinTech #Cybersecurity

Fraud Is a Network, Not a Transaction: Architecting Identity and Payment Graphs for FinTech

Vaibhav Shakya — Tue, 03 Nov 2026 05:09:46 +0000

Fraud Is a Network, Not a Transaction: Architecting Identity and Payment Graphs for FinTech

A transaction can look completely normal when viewed in isolation.

The account is authenticated. The device looks familiar. The amount is within acceptable limits. Transaction velocity has not crossed any configured threshold.

Yet the payment may still sit inside a suspicious network.

That is the key architectural problem with purely transaction-centric fraud detection.

The Problem

Many fraud systems still reason primarily like this:

transaction
    ↓
features
    ↓
score
    ↓
decision

That model is useful, but it can miss coordinated behavior spread across multiple identities and events.

Consider several accounts that:

use the same device
use different payment instruments
stay below individual velocity limits
transfer toward the same beneficiary

Individually, each account may appear normal.

Together, the relationship structure can look very different.

A more relationship-aware pipeline looks closer to:

event
  ↓
resolve entities
  ↓
update relationships
  ↓
inspect relevant neighborhood
  ↓
calculate contextual risk
  ↓
apply policy
  ↓
approve / challenge / review / decline

The transaction still matters.

It is simply no longer the entire unit of reasoning.

Where It Gets Difficult

Graph-based fraud detection introduces several problems of its own.

Entity resolution

Connecting two nodes is easy.

Knowing whether two observations actually represent the same device, person, payment identity, or account is much harder.

A wrong merge can propagate risk across legitimate users.

A missed merge can hide coordinated fraud.

That is why uncertain relationships should remain uncertain instead of being silently promoted into permanent security facts.

Shared infrastructure is not automatically fraud

A device linked to multiple accounts can represent abuse.

It can also represent:

a shared household device
a merchant terminal
a corporate device
a kiosk
a resold phone
legitimate account switching

The same applies to IP addresses and beneficiaries.

Graph density is evidence.

It is not a verdict.

Authentication and fraud are different questions

Successful authentication does not automatically mean a payment is safe.

A system may legitimately have:

authentication confidence = high
transaction risk = high

An attacker may control an authenticated session, or a legitimate customer may be socially engineered into authorizing an unwanted payment.

Fraud decisioning therefore has to survive the authentication boundary.

Freshness and consistency matter

A graph can also produce the wrong answer when its state is stale.

A newly blocked beneficiary may require stronger freshness than historical device relationships.

This means the architecture should not treat every graph signal the same way.

Some can tolerate eventual consistency.

Others may require stronger enforcement semantics.

Architectural Direction

A useful design separates several concerns instead of building one oversized "fraud score."

Clients contribute signals, but the backend remains authoritative.
Entity resolution maps observations into graph identities.
Relationships carry temporal information such as first_seen, last_seen, and observation counts.
Graph-derived features feed rules, statistical models, ML, or manual-review policies.
Risk estimation remains separate from the business policy that decides what action to take.

For example, graph features might include:

device_account_count_24h = 5
beneficiary_unique_senders_1h = 11
account_new_payment_instruments_7d = 4
distance_to_confirmed_fraud = 2
device_relationship_age_seconds = 940

Those values are much easier to operationalize than starting immediately with an opaque graph score.

They can answer questions like:

How many accounts recently used this device?
How quickly are new relationships appearing?
How many independent accounts converge on one beneficiary?
How close is the current entity to confirmed fraud?
Is this relationship minutes old or months old?

Keep the Mobile Client in the Right Trust Boundary

Mobile applications can provide useful observations such as session context, app version, device-bound information, lifecycle state, or platform integrity evidence.

But the client should not determine whether a payment is safe.

The backend should correlate those observations against broader account and graph context.

Conceptually:

Client:
device_key_id = DK-8291

Backend:
DK-8291 belongs to session S18
S18 belongs to account A72
DK-8291 was first observed 14 minutes ago
DK-8291 is also associated with A81 and A93

The client sees its immediate environment.

The backend can see the relationship network.

That distinction is essential.

A Simple Scenario

Imagine 12 customer accounts.

None exceeds an individual transaction threshold.

Each performs only a few low-value payments.

Different payment credentials are used.

From a transaction table, the cases may appear unrelated.

But relationship analysis reveals:

12 accounts
    ↓
3 devices
    ↓
9 payment identities
    ↓
2 beneficiaries

The architectural lesson is not:

shared device = fraud

The lesson is that the original risk boundary stopped at the account.

The attacker did not.

Graph-derived evidence can therefore increase scrutiny without automatically converting every connected account into a fraud case.

The Takeaway

Fraud is often expressed through transactions.

But sophisticated fraud may only become visible through the relationships surrounding those transactions.

Identity and payment graphs can help expose that context, but they do not create certainty.

They introduce their own challenges around entity resolution, false positives, stale state, privacy, idempotency, explainability, and latency.

The goal is not simply to decline more payments.

The goal is to understand risk that exists across identities, devices, payment instruments, beneficiaries, sessions, and historical events — where a transaction-only view may never see it.

Want the deeper architectural breakdown, implementation considerations, failure scenarios, consistency trade-offs, privacy concerns, and full reasoning?

Read the full article on Medium

Follow my work

I write about software architecture, FinTech, AI, cybersecurity, distributed systems, mobile engineering, and production engineering.

Connect with me on LinkedIn

Explore more at vaibhavshakya.com

#FinTech #FraudDetection #SoftwareArchitecture #PaymentSecurity

When Software Gets a Wallet: Architecting Payments for Autonomous AI Agents

Vaibhav Shakya — Wed, 28 Oct 2026 04:29:48 +0000

AI agents are moving from recommendation systems toward systems that can actually take actions.

That becomes much more serious when the action involves money.

An autonomous agent may discover a product, compare alternatives, select a merchant, and initiate a purchase without a human being present at the exact moment payment happens.

At that point, the problem is no longer simply:

How do we let an AI agent pay?

The better question is:

How do we let probabilistic software request economic actions while deterministic systems retain authority over what is actually allowed?

The Problem

The dangerous design is to treat an AI agent like a human user with a wallet.

Giving the model direct access to card numbers, private keys, bank credentials, or unrestricted wallet balances creates an unnecessarily large privilege boundary.

A safer architecture separates responsibilities:

User or business intent
        ↓
AI agent reasoning
        ↓
Structured payment request
        ↓
Policy and risk checks
        ↓
Bounded payment capability
        ↓
Payment infrastructure
        ↓
Merchant
        ↓
Ledger and reconciliation

The model may decide that a purchase is useful.

It should not automatically possess the authority required to execute that purchase.

Where It Gets Difficult

Several problems become significantly more important once agents can initiate payments.

1. Prompt injection becomes a financial-control problem

An agent may read webpages, emails, PDFs, API responses, or merchant descriptions before deciding what action to take.

Any of those inputs could contain misleading or adversarial instructions.

If the same model can both interpret that content and freely spend money, a content-security failure can become a financial loss.

The stronger control is not simply making the model harder to manipulate.

The stronger control is ensuring that even a manipulated model still has to pass an independent payment policy.

2. A timeout does not mean the payment failed

Imagine the agent submits a purchase.

The payment succeeds, but the network response is lost.

The agent sees a timeout.

A naive autonomous system may reason:

No response → probably failed → try again

That can create duplicate charges.

Payment infrastructure therefore needs stable business identifiers and idempotency semantics so that multiple execution attempts can still represent one economic action.

3. Agent memory cannot become the financial ledger

An AI agent may have conversation history, long-term memory, retrieval systems, or stored context.

None of those should be the authoritative source of financial truth.

The backend needs durable records of:

Which user or organization authorized the action
Which agent initiated it
What permission existed
Which policy evaluated it
What amount was requested
What actually succeeded
What retries occurred
Whether approval was required
What was ultimately delivered or refunded

The model's explanation can be useful context.

It should not replace the transaction record.

Architectural Direction

The core design principle is delegated authority.

Instead of giving an agent general permission to "make payments," grant narrowly scoped capabilities.

For example:

Agent A may spend up to ₹5,000
at SOFTWARE merchants
for PROJECT-42
until 18:00 UTC
with a maximum of one transaction.

That is very different from:

Agent A may make payments.

Useful constraints can include:

Maximum amount
Cumulative budget
Merchant or merchant category
Product or SKU
Currency
Validity period
Transaction count
One-time versus recurring payment
Human approval requirements

Not every payment rail supports every restriction directly.

Some constraints may be enforced by the agent platform, some by a backend policy engine, and others by the PSP, payment network, wallet, or merchant.

The important part is that the rules are deterministic and independently enforced.

Human Intent Should Be Durable

Suppose a user tells an agent:

Book me a nonstop flight to Bengaluru next Friday evening for less than ₹9,000.

The payment may happen hours later.

The conversation itself should not be the only proof of authorization.

A stronger system converts that instruction into a durable mandate containing constraints such as:

{
  "action": "purchase_flight",
  "destination": "BLR",
  "departure_after": "18:00",
  "max_amount_minor": 900000,
  "currency": "INR",
  "nonstop_only": true
}

When the agent later finds a flight, the payment system compares the proposed transaction against that stored authority.

The key audit question becomes:

What had the user actually authorized when this transaction executed?

rather than:

What did the model think the user wanted?

Payment State Still Belongs to the Backend

Agents do not remove normal distributed-systems problems.

They make some of them more dangerous.

A payment may move through states such as:

REQUESTED
POLICY_APPROVED
PAYMENT_AUTHORIZED
CAPTURE_PENDING
CAPTURED
FULFILLED

It may also reach states such as:

POLICY_REJECTED
REQUIRES_HUMAN_APPROVAL
PAYMENT_UNKNOWN
CAPTURE_FAILED
REFUNDED
REVERSED

These exact states vary by payment provider and payment rail.

The architectural point is that payment state must be explicit and authoritative.

The agent should not infer financial truth from conversational tool responses.

The Takeaway

The interesting part of an "AI wallet" is not the wallet.

It is the delegation architecture around it.

A trustworthy system needs to establish something equivalent to:

I am Agent X.
I am acting for Principal Y.
Principal Y authorized action Z.
That authority is valid under conditions C.
This requested transaction satisfies those conditions.

The payment infrastructure then independently decides whether those claims are sufficient to allow money movement.

The AI may discover the opportunity and request the purchase.

But identity, policy, scoped authority, transaction state, idempotency, auditability, and reconciliation are what make autonomous payments viable as financial infrastructure.

Want the deeper architectural breakdown, implementation considerations, failure scenarios, and full reasoning?

Read the full article on Medium

Follow my work

I write about software architecture, FinTech, AI, cybersecurity, distributed systems, mobile engineering, and production engineering.

Connect with me on LinkedIn

Explore more at vaibhavshakya.com

#AgenticAI #FinTech #SoftwareArchitecture #Payments

Your AI Agent Needs an IAM Strategy Too: Least-Privilege Design for Autonomous Financial Systems

Vaibhav Shakya — Tue, 27 Oct 2026 04:58:06 +0000

AI agents are moving beyond answering questions.

They can increasingly retrieve financial data, prepare payments, issue refunds, reconcile settlements, create beneficiaries, and trigger actions across backend systems.

Once an agent can perform financial operations, it is no longer just an AI component.

It becomes part of the identity and access management architecture.

The Problem

A common implementation looks simple:

Mobile App → Backend → AI Agent → Financial APIs

The backend already has credentials for internal APIs, so the easiest approach is to let the agent reuse that authority.

That creates a dangerous boundary.

The agent may need permission to perform one specific operation for one customer, but the backend identity may have access to many customers, accounts, payment operations, refunds, configuration APIs, or settlement systems.

The agent effectively inherits authority based on where it runs rather than what the current task requires.

A stronger model is:

User identity → Delegation → Agent identity → Limited capability → Resource authorization

The agent should have identifiable execution context and receive only the authority required for the current workflow.

Where It Gets Difficult

Authentication is not authorization

Knowing that the authenticated customer is user_82741 does not answer:

Can this particular agent transfer ₹18,000 from this account to this beneficiary right now?

Authorization may need to consider:

which user delegated the authority
which agent is acting
which account is involved
which operation is requested
the transaction amount
beneficiary status
consent state
risk state
approval requirements
credential lifetime

A broad permission such as payments:create may therefore be insufficient on its own.

Prompt instructions are not security controls

A system prompt might say:

Never transfer more than ₹25,000.

That can guide model behavior.

It should not be the control that protects the payment system.

If policy says the agent cannot execute ₹25,001, the payment service should reject that transaction regardless of what the model reasons.

The model can decide what it wants to attempt.

Deterministic authorization should decide what it is actually allowed to execute.

Short-lived credentials are not enough

Short credential lifetimes reduce exposure, but they do not fix excessive privileges.

A five-minute administrator credential is still an administrator credential.

Least privilege should reduce both:

how long authority exists
what that authority can actually do

Retries can become financial incidents

Suppose the agent sends a payment request and the network times out before the result is returned.

The orchestration layer retries.

Without idempotency, the same logical payment could potentially be processed more than once.

Authorization and transactional idempotency therefore solve different but complementary problems:

Is this operation allowed?

and:

Has this logical operation already been executed?

Architectural Direction

A safer autonomous financial architecture gives the agent narrowly scoped authority rather than inheriting a broad backend credential.

Useful design principles include:

Give each agent execution an identifiable identity and delegation context.
Prefer task-specific and short-lived authority.
Restrict authority to relevant customers, accounts, resources, and actions.
Separate read, prepare, approve, and execute capabilities when the risk justifies it.
Keep financial limits and business rules outside model reasoning.
Let the protected resource independently authorize the requested action.
Preserve user → agent → policy → tool → transaction auditability.
Combine authorization with idempotency, risk controls, revocation, and monitoring.

For example, an invoice-payment agent might be allowed to prepare a payment for:

Customer A
Funding Account X
Supplier Y
Invoice 7821
Maximum amount ₹42,000
A limited execution window

If the model attempts ₹43,000, policy rejects it.

If it references another customer's account, resource authorization rejects it.

If the request is retried after a timeout, idempotency prevents the same logical payment from becoming another transaction.

The model still contributes intelligence.

It simply does not grant itself authority.

The Takeaway

Autonomous financial systems introduce another identity question into modern architecture.

Traditional IAM asks:

Who is the user?

Distributed systems also ask:

Which workload is calling?

Agentic systems add:

Which agent is acting, under whose authority, and exactly what has it been allowed to do?

An AI agent may reason broadly.

Its financial authority should remain deliberately narrow.

Want the deeper architectural breakdown, implementation considerations, failure scenarios, IAM boundaries, sender-constrained credential discussion, and full reasoning?

Read the full article on Medium:

https://medium.com/@vaibhav.shakya786/your-ai-agent-needs-an-iam-strategy-too-least-privilege-design-for-autonomous-financial-systems-9f54da7b8b28

Follow my work

I write about software architecture, FinTech, AI, cybersecurity, distributed systems, mobile engineering, and production engineering.

Connect with me on LinkedIn:

https://www.linkedin.com/in/vaibhav-shakya-neo/

Explore more at:

https://vaibhavshakya.com

#AIArchitecture #FinTech #Cybersecurity #AgenticAI

Policy Before Prompt: Enforcing Machine-Readable Financial Rules on Autonomous AI Agents

Vaibhav Shakya — Fri, 23 Oct 2026 04:22:50 +0000

An autonomous financial agent receives a simple instruction: pay approved suppliers before their invoices become overdue.

It identifies an invoice, checks the beneficiary, and proposes a transfer. The reasoning looks sensible. But does the customer’s delegation permit the payment? Have the beneficiary’s bank details changed? Has another worker already consumed the remaining spending allowance?

A prompt can describe these constraints. Trusted services must enforce them.

The Problem

“Policy before prompt” describes an order of authority. Financial rules remain authoritative regardless of what the model generates.

The agent proposes a structured operation. The backend verifies resource ownership, retrieves authoritative context, evaluates policy, and satisfies execution conditions.

Fields such as supplier_approved or approval_complete must not become trusted merely because the agent supplies valid JSON.

Likewise, authenticating the agent workload does not establish which customer delegated authority or which accounts that delegation covers.

Where It Gets Difficult

An allow decision does not reserve a budget. Suppose two workers each propose ₹20,000 payments against a remaining allowance of ₹30,000. Both can pass policy evaluation against the same snapshot. An atomic reservation mechanism must coordinate their combined consumption.

Approval must match execution. Human approval should bind to a specific version of the transaction details. Changing the amount, fees, or beneficiary’s underlying bank details should invalidate the previous approval.

A timeout does not establish payment failure. The provider may have accepted the operation before the response was lost. Creating a replacement transfer can produce a duplicate.

Current policy can still receive stale facts. Policy freshness and the freshness of delegation, approval, and beneficiary data require separate controls.

Architectural Direction

A practical execution path should:

Retrieve decision-critical facts from authoritative services.
Require an explicit successful allow decision.
Reserve shared allowances atomically.
Bind approvals and idempotency records to fixed transaction details.
Resolve uncertain provider outcomes through supported recovery procedures.

Enforcement belongs at the financial execution boundary. An early tool-call check helps, but another caller must not be able to bypass the same controls.

The Takeaway

Authorization establishes permission. Transaction coordination and recovery carry that permission through execution.

Machine-readable policy makes financial authority explicit and reviewable. Its effectiveness still depends on trusted inputs, enforced boundaries, and reliable payment state management.

For the full architectural breakdown, Rego example, approval design, and operational considerations:

Read the full article on Medium

Designing FinTech for the Day Everything Fails: Cyberattacks, Outages, Dependencies, and Recovery

Vaibhav Shakya — Wed, 21 Oct 2026 04:08:18 +0000

A payment provider accepts a transaction, but its response never reaches your backend. The customer sees a timeout. An operator considers switching traffic to another provider.

That recovery decision can create a duplicate charge.

FinTech resilience requires more than restoring services. The architecture must preserve financial correctness while transaction outcomes remain uncertain.

The Problem

A local database transaction does not atomically include a payment provider’s processing decision. When a request times out, your backend knows it stopped waiting. It does not necessarily know whether money moved.

Treating that uncertainty as failure can encourage another attempt against an obligation that was already collected.

An explicit state such as OUTCOME_UNKNOWN gives the system something actionable to manage: the original provider reference, the next inquiry, the evidence received, and the threshold for manual review.

Where It Gets Difficult

1. Atomic acceptance does not guarantee external execution

Recording a payment intent and its outbox event in one database transaction closes a local consistency gap.

However, a worker can submit the payment and crash before recording delivery. Processing the outbox again may repeat the external request.

Stable provider identifiers, provider-specific idempotency behavior, and outcome resolution still matter. A unique request key also needs to work alongside an enforced business-operation identity.

2. Provider failover has two separate responsibilities

Routing eligible new payments to another provider differs from resolving payments already submitted.

Independent providers generally do not share an idempotency namespace. An unresolved payment should remain associated with its original provider reference until sufficient evidence establishes its outcome.

3. Restoring data does not restore the outside world

A database recovery point may precede a payment that succeeded externally.

Recreating and resubmitting that missing operation can repeat its financial effect. Recovery therefore needs reconciliation against provider records, authenticated callbacks, settlement evidence, and independently retained transaction evidence.

4. Cyber recovery requires a trusted environment

During an infrastructure outage, moving traffic may restore availability. During a compromise, it may also carry stolen credentials or malicious configuration into the recovery environment.

Isolation, credential revocation, validated deployment artifacts, and rebuilding from a trusted baseline become part of the recovery decision.

Architectural Direction

A practical design should:

Preserve payment identity across retries and mobile-app restarts.
Record accepted work and dispatch instructions atomically.
Separate status inquiries from money-moving submissions.
Apply controlled state transitions and idempotent ledger-posting controls.
Reconcile uncertain operations before reopening capabilities that depend on their correctness.

For example, after a provider timeout, the mobile app retrieves the existing payment rather than creating another one. The backend keeps investigating through the original provider reference.

When an authenticated inquiry confirms success, the backend applies the permitted transition and records the corresponding ledger entry under a unique business reference. A duplicate callback must not create another posting.

The Takeaway

Replication supports availability. Backups provide historical recovery options. Reconciliation accounts for financial effects beyond the restored database.

Recovery dashboards should therefore track unknown-outcome age, reconciliation breaks, settlement delays, and ledger-posting failures alongside infrastructure metrics.

The recovery goal is an explainable financial state, including operations whose answers arrived late.

Want the deeper architectural breakdown, implementation considerations, failure scenarios, and full reasoning?

Read the full article on Medium

Putting a Control Plane Between the LLM and the Bank: Architecture for Governed AI Execution

Vaibhav Shakya — Mon, 19 Oct 2026 04:32:13 +0000

An AI assistant receives a simple instruction: “Pay the approved supplier invoice.”

It identifies the invoice, generates valid JSON, and calls an authenticated tool. Yet the backend still needs to establish whether the customer authorized this exact payment, whether the beneficiary details remain valid, and whether another worker has already submitted it.

These questions belong to the execution architecture.

The Problem

Authentication establishes who is calling. Business authorization determines which financial action that caller may perform.

A workload credential does not, by itself, establish permission to debit a customer’s account. Similarly, a confirmation screen provides limited assurance if the amount or beneficiary can change between approval and execution.

The architectural boundary is straightforward: the model proposes an action, while trusted application code controls its admission and submission.

Where It Gets Difficult

Approval must identify the exact operation

Bind approval to a backend-created payment intent containing the relevant account, beneficiary version, amount, currency, fees, and expiration.

Include the intent identifier and revision so that approval cannot simply be copied onto another payment. Changes to approved details should invalidate the previous approval.

Concurrent workers can consume the same authority

Checking permission and later writing a queue message leaves a timing gap.

Within the application’s consistency boundary, coordinate approval consumption, state transitions, invoice reservations, limit reservations, and durable dispatch preparation.

Locking one intent does not automatically protect an account-wide allowance or prevent a separate intent from paying the same invoice.

A timeout leaves an uncertain outcome

A bank may receive a request even when the execution worker never receives its response.

Creating a replacement payment can therefore introduce a duplicate. Preserve the existing intent and resolve its status through supported lookup, authenticated callbacks, or reconciliation.

Provider idempotency behavior must be checked against the specific endpoint, API version, and retention window.

Architectural Direction

Separate policy management from runtime enforcement.

The control plane manages permitted operations, delegation rules, approval thresholds, policy versions, and emergency restrictions. The execution layer gathers trusted context, evaluates each intent, records the admission decision, and invokes a constrained payment adapter.

A practical implementation should:

Resolve invoice, beneficiary, and delegation details from authoritative backend records.
Keep provider credentials within the execution environment.
Bind approval to an exact, versioned intent.
Coordinate local admission changes with an outbox record.
Handle repeated delivery and uncertain provider outcomes explicitly.

These responsibilities can initially live in one backend application. Separate services should follow operational needs.

A Short Example

A customer approves a ₹48,000 supplier payment on Android. The backend reserves the invoice amount and applicable allowance, then prepares durable dispatch.

The bank response times out.

The application displays “Payment status pending confirmation” and retrieves the same intent when reopened. A later authenticated bank event confirms acceptance, and the backend continues tracking the payment according to the rail’s status model.

The conversation can resume without creating a fresh payment.

The Takeaway

An authorization decision and a payment outcome are separate records.

Governed AI execution needs explicit authority, transaction-bound approval, coordinated admission, and a recovery path for uncertainty. The mobile application and the assistant should explain the backend’s recorded state.

For the admission pseudocode, revocation trade-offs, audit considerations, and full architectural reasoning, read the full article on Medium.

Who Authenticated the Agent? Building Identity for AI That Acts on a Customer’s Behalf

Vaibhav Shakya — Wed, 14 Oct 2026 04:25:22 +0000

Who Authenticated the Agent? Building Identity for AI That Acts on a Customer’s Behalf

A customer asks an AI assistant to pay an invoice. The assistant selects an account and submits the payment through an API.

The backend receives a valid token. But does that token identify the customer, the software executing the action, or both?

A customer credential alone may obscure the executing actor. A service credential alone does not establish the customer’s permission. An agent acting on someone’s behalf needs an enforceable relationship between these identities.

The Problem

Passing the customer’s existing access token into an agent runtime carries session authority into another execution environment. Its permissions may exceed the task, and downstream records may attribute every action solely to the customer.

A clearer architecture separates three concepts:

Customer: Whose resources are affected.
Workload: Which authenticated software invokes the operation.
Delegation grant: What that workload may do for that customer.

Authentication establishes the actor. Delegation defines its authority. Authorization determines whether the requested operation fits that authority.

A prompt saying “you represent this customer” establishes none of those boundaries.

Where It Gets Difficult

Broad consent creates ambiguous authority

“Allow AI access” does not describe a useful payment boundary.

“Pay this biller once, from this account, up to ₹3,000, before this date” can become a structured grant with enforceable constraints.

Natural language may propose the permission. The backend should validate and store the approved policy.

Token protection does not authorize the transaction

Sender-constrained tokens can reduce the usefulness of a stolen token without its associated key. They do not establish customer approval of the payment.

DPoP, for example, does not sign the payment body or bind consent to its amount and beneficiary. Credential protection and transaction authorization address different risks.

Retries interact with consumed grants

Suppose the backend accepts a ₹2,750 payment and reserves the grant’s single permitted operation. The response is lost.

The retry must not consume authority again. After checking access and matching the request, the backend should return the existing operation associated with the scoped idempotency key.

Checking only whether the grant still has unused authority can incorrectly reject that recovery path.

Valid identity does not resolve prompt injection

A retrieved invoice or email may influence a legitimate agent’s tool use.

Backend constraints can reject an excessive amount or unapproved destination. They cannot always detect a harmful decision that remains within a broad grant.

Permission design must account for that residual risk.

Architectural Direction

Keep credentials in a controlled execution component outside model context and generated output. Authenticate the workload independently, then associate its permitted actions with a backend delegation record.

At payment acceptance:

Validate credentials and resolve the customer and current actor.
Check whether the scoped idempotency key already identifies an operation.
For an existing operation, verify access and matching payment details.
For a new operation, enforce grant status, limits, destination, and approval requirements.
Atomically record authorization consumption, idempotency, and durable dispatch intent.

Define how revocation competes with acceptance. Revoking future authority does not necessarily cancel a payment already dispatched.

Preserve the initiating actor and delegation reference across queues and workers. A worker’s service identity should not erase who initiated the business operation.

The Takeaway

An authenticated agent is only one part of the design.

The backend must explain which software acted, whose authority it used, what that authority permitted, and how the operation recovered when execution became uncertain.

Want the deeper architectural breakdown, implementation considerations, failure scenarios, and full reasoning?

Read the full article on Medium

Signing the Intent, Not Just the Request: Designing Transaction Authorization for Mobile FinTech

Vaibhav Shakya — Tue, 13 Oct 2026 04:29:13 +0000

Signing the Intent, Not Just the Request: Designing Transaction Authorization for Mobile FinTech

A customer reviews a ₹5,000 transfer and confirms with a fingerprint.

The application has authenticated the customer locally. But what evidence tells the backend which amount, destination, and charges the customer approved?

That is the architectural problem transaction intent signing addresses.

The Problem

Authentication establishes identity. Transaction authorization determines whether a specific operation may proceed.

A signed request can implement transaction authorization when it contains the complete business contract and execution follows that contract. Problems arise when downstream services reinterpret its meaning.

For example, signing a beneficiary identifier is insufficient if its destination account can change before execution. The signature may remain valid while the payment reaches a different account.

Where It Gets Difficult

Signed bytes must be unambiguous. Ordinary JSON serialization can vary across platforms. Define deterministic encoding, schema validation, numeric limits, and signature rules.

Protected key use does not prove informed consent. Android Keystore and iOS Secure Enclave can protect signing keys and govern their use. They do not independently establish that the application displayed accurate transaction details.

Enrollment is an authorization boundary. If a stolen session can register a replacement signing key, the signing protocol loses much of its value. Enrollment, recovery, and revocation need explicit controls.

Approval and execution have different failure modes. Accepting an approval atomically does not guarantee one-time processing by an external payment provider.

Architectural Direction

Separate preparation, approval, and execution:

The backend resolves the destination and creates an immutable intent containing the material transaction fields.
The application renders the confirmation screen from that intent and signs its defined bytes.
The backend verifies ownership, signature, key eligibility, expiry, and policy before atomically accepting approval and recording a durable execution command.
The execution worker uses the accepted snapshot, checks current execution eligibility, and follows the provider’s supported retry and recovery rules.

A transactional outbox keeps local acceptance and the execution command durable together. Duplicate delivery still requires consumer deduplication.

Consider a lost approval response. The application retries with the same intent identifier, and the backend returns the existing operation’s status. If the provider call later times out, the worker treats the result as uncertain and follows the supported recovery process.

The Takeaway

Transaction authorization requires continuity between what the customer reviews, what the device signs, and what the backend executes.

A signature provides evidence of key use over a defined message. Immutable transaction meaning, trustworthy presentation, backend enforcement, and controlled recovery determine how useful that evidence becomes.

Want the deeper architectural breakdown, implementation considerations, failure scenarios, and full reasoning?

Read the full article on Medium

From Mobile Tap to Autonomous Agent: A Reference Architecture for the AI-Native FinTech Stack

Vaibhav Shakya — Mon, 12 Oct 2026 04:39:07 +0000

AI-native FinTech changes more than the user interface.

It changes how we need to think about authority, execution, and financial truth.

A traditional payment flow is relatively straightforward:

User
  ↓
Mobile App
  ↓
API
  ↓
Financial Service
  ↓
Payment Rail

Introduce an autonomous agent and another decision-making layer appears:

Customer Intent
      ↓
Agent Reasoning
      ↓
Policy / Authorization
      ↓
Financial Services
      ↓
Payment Rail

The important architectural question is no longer only:

Who authenticated?

It also becomes:

What exactly is software acting on behalf of that customer allowed to do?

The Problem

An AI agent can interpret ambiguous instructions, gather information, choose tools, retry operations, and coordinate multiple services.

That flexibility is useful.

But financial systems cannot allow probabilistic reasoning to become the final source of authority.

Consider a customer instruction:

Pay my broadband bill every month if it stays below ₹1,500.

This is not a direct payment command.

It contains several constraints that first need to become structured financial intent:

{
  "intentType": "PAY_BILL",
  "billerId": "ISP_291",
  "maximumAmountMinor": 150000,
  "currency": "INR"
}

The agent can help interpret the instruction.

But the payment system should execute the structured contract—not the original natural-language sentence.

That boundary creates a useful architectural rule:

Reasoning may be probabilistic. Financial execution should remain deterministic.

Where It Gets Difficult

1. Authentication is not delegated authority

A customer may successfully authenticate, but that does not mean an agent should automatically receive every permission available to the customer.

Instead of handing the agent broad account authority, the platform can create a bounded delegation:

action: PAY_BILL
biller: ISP_291
maxAmount: 150000
expiresAt: ...

The exact implementation might use scopes, server-side grants, capability tokens, mandates, or another authorization model.

The principle is the same:

Give the agent only the authority required for the specific task.

2. Tool access is not transaction authorization

An agent might have an approved capability such as:

executePayment()

That does not mean every invocation should execute.

A specific request could still violate:

delegated amount limits
beneficiary restrictions
transaction velocity rules
account state
risk policy
regulatory controls

The tool answers:

Can the agent request this type of operation?

The policy layer must still answer:

Can this exact operation execute now?

3. Retries become dangerous around money

Imagine the agent submits a payment.

The processor receives and completes it, but the network response is lost.

The agent sees:

TimeoutException

A reasonable software reaction might be:

Retry.

But:

No response != No payment

If the retry creates a new transaction, an ordinary distributed-systems timeout becomes a duplicate-payment problem.

The safer approach is to create a stable operation ID and query the existing payment state.

For example:

P7123

PROCESSING
   ↓
UNKNOWN
   ↓
RECONCILED
   ↓
SUCCEEDED / FAILED

An uncertain state is better than falsely declaring failure.

4. Agent memory cannot become financial truth

The agent may say:

I paid your broadband bill.

That statement is conversational state.

It is not accounting evidence.

The authoritative result should come from the financial platform:

Agent requests payment
        ↓
Payment service creates operation
        ↓
Processor invoked
        ↓
Provider result / event received
        ↓
Authoritative transaction state advances
        ↓
Agent reads final state

The direction matters.

Financial state informs the agent.

The agent should not tell the financial system what happened merely because the model believes it happened.

Architectural Direction

A practical AI-native FinTech stack can separate responsibilities into several boundaries:

Mobile / Web Client
        ↓
Identity + Device Signals
        ↓
Intent Service
        ↓
Agent Runtime
        ↓
Policy & Authorization Engine
        ↓
Capability Gateway
        ↓
Financial Domain Services
        ↓
Payment Orchestrator
        ↓
Ledger / Authoritative State
        ↓
Banks / Networks / Payment Rails

A few principles become especially important.

Convert natural-language requests into structured intents before financial execution.
Keep enforceable financial rules outside prompts.
Give agents narrowly scoped capabilities rather than unrestricted service access.
Revalidate authorization immediately before consequential execution.
Use stable operation identifiers and idempotency for retry-sensitive mutations.
Represent pending and ambiguous outcomes explicitly.
Keep conversational state separate from authoritative financial state.
Design reconciliation as part of the payment flow, not as an afterthought.
Correlate customer, device, agent, policy, and payment identities for auditability.

Events Matter Too

AI workflows should not become the synchronization mechanism for the entire financial platform.

Many important payment outcomes happen asynchronously:

processor callbacks
settlement
reversals
refunds
fraud decisions
reconciliation findings

A payment platform may therefore produce events such as:

PaymentRequested
PaymentAuthorized
PaymentSubmitted
PaymentSucceeded
PaymentFailed
PaymentReversed
SettlementCompleted

But asynchronous architecture introduces its own failure modes.

Messages may be delivered more than once.

Consumers may crash and retry.

A database write may succeed while event publication fails.

Ordering may differ from expectations.

Patterns such as a transactional outbox can help coordinate local state changes and event publication, but consumers should still tolerate duplicate delivery.

Exactly-once assumptions are dangerous around money.

A Simple Example

Consider the customer's instruction:

Pay my broadband bill every month if it remains below ₹1,500.

The platform stores a bounded delegation.

Later, a ₹1,249 bill arrives.

The agent prepares the payment.

Before execution, deterministic systems verify:

the biller is approved
the amount is below the delegated limit
the authorization has not expired
relevant account and risk conditions still permit execution

The orchestrator creates payment operation P7123.

The provider processes the transaction, but the response times out.

A weak implementation creates another payment.

A stronger implementation asks:

What is the state of P7123?

The transaction remains PROCESSING.

Later, the provider reports success.

The authoritative financial state moves to SUCCEEDED.

Only then does the agent tell the customer that the payment completed.

The agent did not decide that money moved.

It observed financial state produced by the payment platform.

That distinction is fundamental.

The Takeaway

AI agents can reduce friction across financial workflows.

They can understand intent, coordinate services, personalize experiences, and automate decisions that previously required multiple screens and manual actions.

But greater autonomy requires stronger infrastructure underneath:

bounded delegation
least privilege
deterministic authorization
capability isolation
idempotent execution
explicit transaction state
reconciliation
auditability
revocation
observability

The architecture should not become:

Mobile App
   ↓
AI Agent
   ↓
Payment API

A safer direction is:

Customer Intent
      ↓
Bounded Delegation
      ↓
Agent Reasoning
      ↓
Deterministic Policy
      ↓
Controlled Capability
      ↓
Financial State Machine
      ↓
Authoritative Financial State

The interface may become conversational.

The orchestration may become intelligent.

The customer may perform fewer explicit actions.

But the closer software gets to autonomous money movement, the more precisely the platform must define where reasoning ends and financial authority begins.

Want the deeper architectural breakdown, implementation considerations, failure scenarios, and full reasoning?

Read the full article on Medium

#FinTechArchitecture #AgenticAI #PaymentSystems #SoftwareArchitecture

From Document Upload to Provenance Chain: Architecting Verifiable Evidence for AI-Assisted KYC

Vaibhav Shakya — Thu, 08 Oct 2026 04:50:48 +0000

A customer uploads an identity document.

OCR extracts the name and document number. A model classifies the image. Another component detects suspicious regions. AI compares extracted attributes with application data, and eventually the customer becomes KYC-approved.

From the application perspective, this can look simple:

Document Upload
    ↓
OCR
    ↓
AI
    ↓
KYC Approved

Architecturally, that hides an important question:

Can we reconstruct exactly what evidence, transformation, model, rule, and human decision produced the final result?

That is where KYC starts becoming an evidence provenance problem rather than only a document-processing problem.

The Problem

A document is evidence.

An OCR result is a derived interpretation of that evidence.

An AI-generated conclusion is another derived claim.

A final KYC status is a policy or human decision based on some combination of those artifacts.

These should not be treated as equivalent.

For example, OCR may correctly extract:

Name: Rahul Sharma
Document Number: ABC12345

That does not prove the document is genuine.

Similarly, a cryptographic hash can help establish that stored bytes have not changed, but it does not establish that the underlying document is authentic.

The architecture needs to preserve these distinctions.

Where It Gets Difficult

1. Derived data can silently replace evidence

Suppose OCR initially extracts the wrong document number and a later model produces the correct value.

If the system simply updates:

document_number = corrected_value

the historical reasoning disappears.

A better model keeps the lineage:

SOURCE_DOCUMENT:v1
    ↓
OCR_RESULT:v3
    ↓
ATTRIBUTE_SET:v2
    ↓
POLICY_EVALUATION:v7
    ↓
KYC_DECISION:v1

If OCR is rerun later using another model version, it should create another branch rather than rewrite the evidence used by the original decision.

2. AI inference can become accidental truth

AI may be useful for:

comparing names,
identifying inconsistent fields,
classifying unusual layouts,
summarizing discrepancies,
prioritizing manual reviews.

But an AI result should remain a derived claim.

If one document contains:

VAIBHAV S SHAKYA

and another contains:

VAIBHAV SHAKYA

a model may conclude:

Likely same identity

That conclusion can be useful without rewriting either source.

The system should preserve:

both source values,
the comparison operation,
model or algorithm version,
resulting interpretation,
downstream policy decision.

3. Retries can create competing evidence chains

Imagine an upload reaches the backend, but the client times out before receiving the response.

The client retries.

Without idempotency, the platform may create two evidence records, trigger two OCR jobs, and run two policy evaluations for what the user considers one submission.

One branch may pass automatically while another reaches manual review.

For evidence-processing workflows, idempotency is not only a reliability concern.

It protects the coherence of the provenance chain.

4. Current state is not historical reasoning

A customer profile might contain:

kyc_status = VERIFIED
verified_name = "Ananya Rao"
risk_level = LOW

That is useful operational state.

It cannot answer:

Which artifact introduced the name?
Which validator confirmed it?
Which model or normalization version processed it?
Which policy approved the customer?
Did a reviewer override an earlier decision?

Current state and historical evidence usually need different models.

Architectural Direction

A stronger design treats every material artifact as part of a provenance graph.

The raw uploaded document becomes a source node.

Every processor creates a derived artifact that references its input.

Conceptually:

Raw Evidence
    ↓
OCR Extraction
    ↓
Document Validation
    ↓
Attribute Verification
    ↓
AI Interpretation
    ↓
Policy Evaluation
    ↓
Human Review
    ↓
KYC Decision

A few principles make this architecture much easier to reason about.

Preserve source evidence separately

Do not retain only the resized, enhanced, cropped, or OCR-optimized representation.

Where retention policy permits, preserve the original source artifact separately from derived versions.

Build around evidence IDs

Derived artifacts should reference their parent evidence instead of overwriting it.

For example:

Evidence derived = evidenceRepository.append(
    Evidence.create(
        EvidenceType.OCR_RESULT,
        rawDocument.id(),
        sha256(ocrJson),
        ocrEngine.version(),
        clock.instant()
    )
);

The important idea is append.

The OCR result becomes another artifact in the chain.

Keep inference separate from policy

Avoid allowing a probabilistic component to directly mutate customer state:

model.score > 0.91
→ VERIFIED

Prefer:

AI inference
    ↓
Derived signals
    ↓
Versioned policy
    ↓
APPROVE / REVIEW / REJECT

The model produces signals.

The policy decides what the organization is allowed to do with those signals.

Version anything that can influence a decision

That may include:

OCR models,
AI models,
normalization algorithms,
prompt or task definitions,
schemas,
policy rules,
decision thresholds.

Without versions, historical reconstruction becomes guesswork.

A Practical Example

Suppose rejection rates suddenly increase after a deployment.

The current database only says:

status = REJECTED
reason = NAME_MISMATCH

Without provenance, engineers start reproducing uploads and searching logs.

With lineage, they can follow the decision.

The rejection used policy version 17.

Policy version 17 evaluated:

RAHUL K SHARMA

That value came from normalization service version 6.

The parent OCR value was:

RAHUL KUMAR SHARMA

Another evidence source contained:

RAHUL SHARMA

The customer's documents did not change.

The transformation in the middle of the chain did.

That is exactly what evidence provenance should make visible.

The Takeaway

AI-assisted KYC should not treat the uploaded document, AI output, and final KYC status as interchangeable truth.

They represent different layers:

Evidence records what existed.

Interpretation records what the system inferred.

Policy records what the organization decided to do with that inference.

The goal is not to log everything forever.

The goal is to make consequential decisions reconstructable without silently destroying the evidence and reasoning that produced them.

Want the deeper architectural breakdown, implementation considerations, failure scenarios, privacy trade-offs, cryptographic chaining discussion, and full reasoning?

Read the full article on Medium

#SoftwareArchitecture #ArtificialIntelligence #KYC #SecurityArchitecture