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?
Top comments (2)
The enrollment point is the one that decides whether any of this holds. A signed intent is only as strong as the key registration behind it, and if a stolen session can trigger rotation, the signature proves nothing about consent. Separating preparation, approval, and execution with an immutable intent also maps cleanly onto how settlement systems already think about idempotency, which makes the architecture easier to adopt than the framing suggests.
this is super slick, using the fingerprint to sign the intent rather than just the request really tightens the auth surface and keeps the flow user‑friendly