Source-linked AI summary
FST Pay: Deterministic Safety-Gated Architecture for Youth Digital Payments
Shaikh Mohammed Burhan, Syed Farhaan Quadri, Tabassum Nahid Sultana
TL;DR
Youth access to real-time digital payments creates safety risks that conventional static controls and probabilistic authorization do not fully address. FST Pay places deterministic invariant checks and guardian review on the authorization path while isolating generative AI downstream, presenting an auditable architecture whose production validation remains future work.
Problem
Existing payment platforms lack a unified youth-safety framework combining deterministic policy validation, guardian co-signing, and asynchronous read-only explanation, while probabilistic authorization weakens predictability and auditability.
Method
FST Pay uses six deterministic safety invariants to classify transactions as ALLOW, REVIEW, or BLOCK, with downstream generative AI consuming finalized read-only events without ledger mutation authority.
Results
FST Pay specifies a deterministic authorization architecture that separates real-time transaction safety from downstream natural-language financial explanation.
Takeaways & Limitations
The architecture provides a structured foundation for auditable youth payment systems and future empirical evaluation on real-world platforms.
Takeaways & Limitations
FST Pay has not undergone wide-scale consumer field deployment, so empirical validation across diverse user cohorts remains future work.
Abstract
from arXiv · showhide
Digital payment infrastructures increasingly provide adolescent users with direct access to real-time financial services. While early access promotes financial literacy and digital inclusion, it exposes young users to severe risks of impulsive spending, social engineering frauds, unauthorized transactions, and merchant exploitation. Conventional countermeasures rely on probabilistic machine learning or rigid static controls. However, allowing probabilistic or generative artificial intelligence (AI) models to directly influence real-time payment authorization introduces non-determinism, unpredictable edge-case behavior, and critical audit vulnerabilities. This paper introduces Financial Safety for Teens Pay (FST Pay) as an architectural and formal specification. FST Pay is founded on an immutable operational boundary: strict deterministic safety gating on the real-time authorization path coupled with decoupled downstream AI explanation. Transactions initiated via rails like UPI are subjected to six deterministic invariant checks covering spending limits, guardian co-sign policies, transaction amount thresholds, merchant category codes, temporal access intervals, and hardware integrity constraints. Transactions are classified strictly into ALLOW, REVIEW, or BLOCK outcomes through an ordered, mutually exclusive decision function. High-risk transactions trigger an asynchronous guardian co-sign workflow. Generative AI is relegated entirely downstream of settlement, consuming published post-decision events solely to generate natural-language financial insights without holding mutation privileges over the ledger.
I. INTRODUCTION
FST Pay addresses youth payment risks by separating deterministic authorization from downstream AI explanation. Its architecture applies explicit safety controls and routes higher-risk transactions through guardian oversight without giving AI ledger mutation authority.
- I. INTRODUCTION: Adolescent access to digital payments creates exposure to impulsive overspending, deceptive gamification, phishing, and social engineering.Standard banking often assumes adult autonomy, whereas custodial accounts can restrict minors too severely for autonomous learning.
- I. INTRODUCTION: Probabilistic fraud classifiers are unsuitable as primary authorization arbiters for minors because opaque boundaries and model drift weaken auditability and predictable guarantees.The paper distinguishes macroscopic fraud detection capability from the stricter guarantees required for legal guardianship.
- I. INTRODUCTION: Parents and adolescents need natural-language rationales explaining restrictions and safer spending patterns rather than obscure denial codes.The paper positions explainability as a user-facing requirement for restricted or suspended payments.
- I. INTRODUCTION: FST Pay establishes a deterministic safety-gating architecture that separates real-time authorization from downstream generative explanation.The authorization path excludes probabilistic and generative components, while post-decision events support plain-language educational summaries.
- I. INTRODUCTION: The design formalizes guardian co-signing, non-interference for post-decision AI, and an auditable end-to-end youth payment architecture.Its stated contributions include synchronous multi-party consent holds, capability isolation, UML interaction flows, and a normalized relational schema.
A. Youth Financial Inclusion and Payment Rails
The paper situates youth payment safety within expanding interoperable payment access and limitations of existing fraud and explainability approaches. It proposes a unified framework combining deterministic policy validation, guardian co-signing, and read-only generative explanation.
- A. Youth Financial Inclusion and Payment Rails: Youth digital inclusion requires protective scaffolding because minors face distinct behavioral and digital exploitation threats.UPI provides instant account-to-account settlement, while user-level risk limits and behavioral controls remain relevant design concerns.
- A. Youth Financial Inclusion and Payment Rails: Fraud-detection models can achieve high AUROC but require substantial computation, face concept drift, and do not provide hard guarantees for statutory or contractual enforcement.These properties motivate deterministic controls on the authorization path.
- A. Youth Financial Inclusion and Payment Rails: Existing platforms generally rely on static rules without contextual explanation or end-to-end neural pipelines that weaken auditability and latency guarantees.The paper identifies a gap in unified youth-focused safety architecture.
- A. Youth Financial Inclusion and Payment Rails: The formal model extends attribute-based access control with dynamic expenditures, merchant categories, curfews, and multi-party supervisory escalation.These dependencies are represented in a six-dimensional invariant evaluation vector.
- A. Youth Financial Inclusion and Payment Rails: FST Pay maps each transaction deterministically into the mutually exclusive outcomes ALLOW, REVIEW, or BLOCK.The closed outcome space replaces probabilistic scoring or unconstrained language-model evaluation on the authorization path.
B. Mathematical Formalization of the Safety Invariant Model
FST Pay formalizes payment requests as immutable tuples evaluated against six deterministic safety invariants. These checks distinguish autonomous clearance, guardian review, and blocking based on spending, merchant, temporal, and hardware conditions.
- B. Mathematical Formalization of the Safety Invariant Model: Each transaction request is represented as an immutable tuple containing user, payee, amount, timestamp, device telemetry, and contextual attributes.The tuple captures the inputs required for deterministic invariant evaluation.
- B. Mathematical Formalization of the Safety Invariant Model: Whitelisted or verified minor-safe merchants may be autonomous, while unverified or high-value categories require co-signing and prohibited categories are blocked.The merchant universe is partitioned into ℳauto, ℳcosign, and ℳprohibited, with guardian threshold θcosign governing autonomous execution.
- B. Mathematical Formalization of the Safety Invariant Model: The model evaluates six invariants covering rolling velocity, autonomous clearance, transaction ceiling, merchant category, curfew interval, and platform root-of-trust attestation.Together, these checks form the invariant vector ℐ.
- B. Mathematical Formalization of the Safety Invariant Model: Velocity-limit breaches are diverted to supervisory review rather than discarded, whereas hard transaction-ceiling violations halt checkout immediately.This distinguishes escalation conditions from fatal parameter violations.
- B. Mathematical Formalization of the Safety Invariant Model: Curfew enforcement restricts transactions outside configured operating windows, and hardware attestation verifies device integrity before authorization.These checks extend payment control beyond amount and merchant policy.
C. Deterministic Decision Function
FST Pay maps each transaction deterministically to ALLOW, REVIEW, or BLOCK through an ordered evaluation of six safety invariants.
- C. Deterministic Decision Function: The decision engine deterministically maps each transaction request to ALLOW, REVIEW, or BLOCK.Its formal signature is 𝒟: 𝒯req → Ω.
- C. Deterministic Decision Function: Requests enter REVIEW when fatal violations are absent but automatic or spending-related supervisory conditions fail.The supplied decision specification identifies 𝐼auto and 𝐼s as REVIEW triggers.
- C. Deterministic Decision Function: Fatal violations of amount, merchant, temporal, or hardware invariants immediately produce BLOCK.These checks are evaluated before supervisory escalation conditions.
- C. Deterministic Decision Function: A transaction reaches ALLOW if and only if all six invariants evaluate to 1.The ordered precedence makes the outcomes mutually exclusive.
D. The Architectural Non-Interference Invariant
FST Pay isolates downstream generative AI from authorization authority by restricting it to explanations based on immutable post-decision state.
- D. The Architectural Non-Interference Invariant: Downstream AI explanation is a decoupled function that consumes only post-decision transaction state.The execution context includes the request, invariant vector, and ledger commit time.
- D. The Architectural Non-Interference Invariant: The immutable execution context is X = (R, ℐ(R), τ), committed when the transaction reaches the ledger.This context parameterizes the explanation function.
- D. The Architectural Non-Interference Invariant: Explanation services hold no mutation rights over authorization states.Read-only Kafka credentials and separate database connection pools enforce the isolation.
IV. SYSTEM ARCHITECTURE
FST Pay separates authorization from explanation into a low-latency deterministic pre-authorization stage and an out-of-band post-decision AI stage.
- IV. SYSTEM ARCHITECTURE: The pre-authorization service evaluates invariant checks concurrently with in-memory lookups in under 1 ms.The gateway targets an overall p99 latency below 15 ms without probabilistic dependencies on the critical rail.
- IV. SYSTEM ARCHITECTURE: The post-decision service consumes verified ledger records and invokes isolated language-model endpoints for summaries and compliance reports.It operates out of band on committed event streams rather than authorizing transactions.
B. Component Decomposition
FST Pay decomposes the payment system into client, guardian, gateway, deterministic evaluation, rail, and event-processing components connected by an ordered authorization pipeline.
- B. Component Decomposition: The system includes adolescent and guardian applications, an API gateway, a deterministic rule evaluator, and banking infrastructure.The guardian application supports push-notification co-signing and limit adjustments.
- B. Component Decomposition: The pipeline validates identity and signed ingress data before evaluating cached spending limits and cumulative expenditure.Inactive or suspended accounts and fatal limit overages produce deterministic BLOCK responses.
- B. Component Decomposition: The multi-participant sequence connects the adolescent client, API gateway, safety engine, guardian application, and UPI rail or core switch.The safety engine evaluates the invariant vector against active in-memory state caches.
- B. Component Decomposition: Figure 1 presents the complete multi-tier production software architecture.The supplied caption identifies the figure as the system-wide architecture diagram.
- B. Component Decomposition: Rail settlement and ledger commitment occur before event publication across the authorization boundary.This ordering separates committed payment execution from downstream processing.
VII. DATA MODEL
FST Pay uses a relational data model and independent services to preserve transactional invariants, support deterministic verification, and isolate asynchronous AI explanation.
- VII. DATA MODEL: The schema separates adolescent and guardian identities, relationships, wallets, spending limits, transactions, and explanation logs.This structure distinguishes supervisory relationships and dynamic restrictions from immutable transaction records.
- VII. DATA MODEL: Independent microservices divide deterministic invariant evaluation from Python-based asynchronous language-model orchestration.The architecture uses Java and Spring Boot for invariant evaluation and Python services for downstream LLM workflows.
- VII. DATA MODEL: The invariant service performs sub-millisecond in-memory checks while maintaining active spending totals in Redis sliding-window counters.These counters support rolling spending-limit verification with high availability.
- VII. DATA MODEL: A UPI settlement adapter handles encrypted mutual-TLS integration, while Kafka dispatches post-settlement or rejection events to downstream workers.The dispatcher and generative worker remain separate from payment-rail settlement.
B. Idempotency and Concurrency Control
FST Pay prevents duplicate concurrent payments through UUIDv4 idempotency keys and atomic database insertion, while its evaluation framework remains proposed rather than empirically validated.
- B. Idempotency and Concurrency Control: Concurrent duplicate requests are rejected after atomic idempotency-key insertion, ensuring balances update without race conditions.The client generates a UUIDv4 key, and the database uses ON CONFLICT DO NOTHING during authorization.
- B. Idempotency and Concurrency Control: The paper reports no simulated or fabricated benchmark metrics as proven experimental results.Its evaluation framework is proposed for validation in future testbed implementations.
- B. Idempotency and Concurrency Control: The paper includes figures and a proposed operational-metrics table alongside the concurrency-control description.These visuals provide architectural and evaluation-framework context rather than reported benchmark outcomes.
B. Theoretical Comparative Analysis
FST Pay contrasts deterministic, guardian-aware controls with probabilistic, generative, and conventional banking paradigms while restricting downstream AI to read-only explanation and privacy-preserving inputs.
- B. Theoretical Comparative Analysis: The downstream explanation engine has read-only event access and cannot settle payments, update balances, or alter authorization outcomes.Least-privilege isolation removes network routes, database permissions, and settlement-capable credentials.
- B. Theoretical Comparative Analysis: Prompts exclude personally identifiable information by tokenizing or stripping user identifiers, phone numbers, and bank-account numbers.The model receives only broad descriptors such as amount, merchant category, and triggered policy rule.
- B. Theoretical Comparative Analysis: Table II provides a qualitative design-time comparison of FST Pay with probabilistic fraud detection, unconstrained generative agents, and static retail banking.The comparison concerns architectural paradigms rather than empirical benchmark performance.
- B. Theoretical Comparative Analysis: Encrypted cold-storage logs use time-to-live expiration schedules aligned with youth data-privacy frameworks.This completes the stated data-sanitization and retention controls for explanation processing.
XI. LIMITATIONS AND FUTURE WORK
FST Pay presents a deterministic youth-payment architecture that separates real-time safety gating from read-only generative explanation, but remains subject to operational and validation limits.
- XI. LIMITATIONS AND FUTURE WORK: Operational limitations include absent production benchmarks, guardian-response delays, potentially deceptive merchant categories, and unverified non-interference properties.Future work includes field validation, fallback policies, verified merchant registries, and machine-checked formal verification.
- XII. CONCLUSION: FST Pay separates deterministic real-time safety gating from downstream generative explanation to address transaction safety and user transparency together.The architecture is intended for youth-oriented financial ecosystems.
- XII. CONCLUSION: The authorization engine evaluates six invariants and guardian co-sign holds, while downstream AI explains finalized events without ledger authority.The separation is designed to remove AI hallucination risks from financial clearance and support future real-world evaluation.