Key takeaways

• Agentic commerce is accelerating, but bank-based payments remain workflow-heavy. Users face multiple interfaces, fragile sessions, and unclear status states when making payments.
• Open banking frameworks in the U.S. are primarily about consumer-permissioned data access; they do not require banks to let third parties initiate or manage payments via the same interfaces.
• Real-time rails (RTP and FedNow) increase the stakes: funds move in seconds and payments are designed for certainty, which elevates the importance of explicit authorization and strong controls.
• AppBrilliance enables bank-based agentic payments without autonomous spending: users initiate deterministic sessions that transform bank UIs into streamlined embedded checkout flows, while the user remains present for authentication, terms acceptance, and final authorization.
• Self-Tokenized Sessions (STS) solve the credential problem without turning AppBrilliance into a credential vault: session tokens may be stored on the user’s own device and are never retained by AppBrilliance. Users optionally use these self-tokenized sessions to initiate and complete payment flows.
• Execution inside online banking – clicks, enrollment, approvals – requires a different architecture and a different risk posture than is provided or possible with traditional data aggregation and open banking platforms.

The infrastructure gap: open banking in the US means data access, not payment execution

“Agentic payments” is often described as an agent spending on your behalf. That framing skips over the messy part of bank-based payments: even when the money movement rail is fast, the user experience is still a workflow that spans interfaces, authentication steps, and fragile handoffs.

A request-for-payment (RfP) checkout today starts in a merchant checkout, only to be redirected into a bank connection flow, third-party data aggregation for authentication, to then interact with a bank app notification or email, a separate login and authentication into the bank’s app or website, only to try and find the right request inside online banking, first enrolling and accepting usage terms and conditions, to then authorize the payment, and then return to the merchant – hoping the original session did not time out or lose focus/context.

In the United States, the most prominent regulatory workstream in this space – the CFPB’s Personal Financial Data Rights (PFDR) rule under Section 1033 – is fundamentally a data-access rule. The CFPB explicitly notes that the final rule requires data providers to share information and does not require them to allow third parties to initiate payments using that information.

Agentic payment concepts often assume that write-enabled, standardized interfaces that can initiate payments exist, or are on the horizon. Today, for most banks and most consumer use cases, that assumption is not the reality – and it is not what Section 1033 was designed to mandate.

It is also important to acknowledge regulatory uncertainty. As of October 29, 2025, a federal court stayed the PFDR rule’s compliance dates in the Forcht Bank litigation, and the CFPB has launched an Advanced Notice of Proposed Rulemaking (ANPR) to reconsider aspects of the rule. That means timelines, requirements, and market structure are still evolving.

For many consumer payment use cases, pay-by-bank still lives inside an authenticated bank experience (web or mobile). If we want agentic commerce to reach bank-based payments, we have to design for the world where the bank UI remains the place where enrollment happens, terms are accepted, and payments are authorized – even when the merchant experience is digital-first.

Why autonomous bank-payment agents collide with today’s trust and policy frameworks

The fastest way to make an agent “do what a user can do” in online banking is to give it durable access. In practice, that tends to imply credential custody (stored credentials, reusable tokens, or unattended access). That is where trust breaks – and where regulators, banks, and security teams get uncomfortable.

The CFPB’s PFDR final rule provides a useful window into why. In the rulemaking discussion, the CFPB explains that its authorization and authentication requirements do not accommodate data-access arrangements in which a third party retains consumers’ access credentials.

The Congressional Research Service describes screen scraping plainly: consumers provide their account credentials to a third party, which then accesses account information through the financial institution’s user interface – an approach CRS notes can present additional privacy and data security risks.

Separately, the FFIEC’s interagency guidance on authentication and access management underscores a risk-based approach to authentication that includes third parties and digital banking services. The takeaway for payments is simple: stronger authentication, clear user authorization, and auditable controls are not optional if money is moving.

This is also why data aggregation alone cannot solve payment execution. Aggregators (and most open banking connectors) are built to retrieve and normalize data. Executing a payment in online banking is different: it requires user-visible actions, step-up authentication, terms acceptance, and a final authorization moment. Converting a data-access model into an action-execution model often implies moving into credential retention – exactly the posture regulators are trying to reduce.

Real-time rails raise the stakes: when payments are instant, real user authorization becomes sacred

Instant payment rails are built for speed and certainty, which is precisely why the user authorization moment is the trust anchor. The Federal Reserve’s FedNow Service processes and settles individual payments within seconds, 24x7x365, and requires participating institutions to make funds available immediately after settlement notification. The Clearing House’s RTP network is almost identical, including “payment certainty”, where sending institutions are not able to revoke or recall a payment once it has been submitted. Settlement is final and irrevocable.

In card payments, dispute handling is built into the ecosystem. In instant account-to-account rails, the system design goal is different: certainty and immediate funds availability. The implication for agentic payments is clear: you need humans in the loop when the payment is actually authorized.

The false choice: friction tax vs. autonomy-at-all-cost

This is where the market falls into a false dichotomy:

• Do nothing and accept a friction tax (multi-app journeys, timeouts, abandoned sessions, and support burden) that keeps pay-by-bank from becoming a default checkout option.
• Or push toward autonomous payment agents that require durable access into consumer banking – and then spend the next decade negotiating security, liability, and policy objections.

Neither path is good enough if we believe agentic commerce is real and bank-based real-time payments are inevitable. At AppBrilliance, we believe the winning approach is a third path: human-in-the-loop agentic payments.

The AppBrilliance approach: user-in-the-loop deterministic session orchestration

AppBrilliance defines agentic payments as background orchestration that keeps the user in the loop at the authorization point while automating the payment workflow around it. Instead of delegating spending power to an autonomous agent, we remove the dozens of steps and context switches that make bank-based payments feel fragile.

Architecturally, users initiate personal, deterministic agentic browsing sessions on the back end. These sessions interact with the bank’s existing online banking experience and transform it into a streamlined, embeddable checkout flow – without removing the human authentication and authorization steps that banks rely on to manage risk and support their control environment.

This is a crucial distinction: AppBrilliance is not asking banks to expose write-enabled APIs that do not exist in most consumer contexts. We are making the bank’s existing experience checkout-native, while preserving the bank’s own authentication, disclosures, and authorization controls.

What stays human vs. what becomes automated

A practical way to evaluate agentic payment systems is to separate the steps that must remain explicitly human from the steps that should never have required human attention in the first place:

User remains in control for:

• Bank authentication (user signs in with their own credentials).
• Enrollment and terms acceptance (where required by the bank or rail).
• Verification of the payment specifics (source of funds, amount).
• Final payment authorization (the explicit consent moment).

AppBrilliance simplifies and orchestrates:

• State management across interfaces (no more “hope the session is still alive”).
• Navigation and presentation of the required bank UI elements inside checkout.
• Timing, handoffs, and recovery paths for common interruptions (timeouts, re-authentication, step-up challenges).
• Clear, closed-loop status back to the merchant experience.

STS (Self-Tokenized Sessions): solving the credential problem without becoming a credential vault

If bank-based payment execution still happens inside authenticated online banking, then the credential problem is unavoidable. The system must enable the user to authenticate in a manner consistent with the bank’s authentication experience and controls, with appropriate access, and it must do so without turning the platform into a repository of consumer credentials and sensitive financial information.

AppBrilliance addresses this with STS (Self-Tokenized Sessions). When a user interacts with their bank through our platform, they can optionally store a self-tokenized session on their own personal device. That token is used to initiate deterministic agentic sessions, while AppBrilliance avoids storing or retaining the user’s credentials.

The design goal is to preserve user-in-the-loop control while reducing repeated logins and drop-off. Users can engage an agentic payments flow without turning AppBrilliance into a credential vault.

The intent is alignment with where policy is heading: moving away from third-party credential retention and toward safer, user-controlled access patterns. The CFPB’s PFDR rulemaking discussion, for example, emphasizes that authorization and authentication frameworks should not rely on third parties retaining consumer access credentials.

Agentic payments without data hoarding: minimal data access, purpose limitation, and account validation

A common misconception is that UI orchestration requires broad data scraping. Our architecture is deliberately narrower. AppBrilliance accesses only what is necessary to initiate the payment flow and meet relevant network rules and operational requirements (for example, basic account information needed to route a payment or validate account details).

Account validation is a real, explicit expectation in legacy payment networks. Nacha’s guidance describes validating first-use consumer account information for certain ACH use cases and frames account validation as part of fraud detection practices.

Why this is the reality-based path for agentic payments

Agentic commerce will not be limited by AI capability; it will be limited by whether systems can complete outcomes inside the constraints of trust, regulation, and real financial infrastructure.

That is why AppBrilliance is intentionally not building a “black box spender.” We are building an orchestration layer that makes bank payments checkout-native while keeping the user present at the trust boundary. This matches how real-time rails operate (speed + certainty) and how authentication guidance is written (risk-based controls, third-party considerations, and enforceable consent).

If you want bank-based, real-time agentic payments to scale, you need a platform that (1) removes workflow friction, (2) does not require third-party credential custody, and (3) preserves explicit user authorization. Otherwise, you either accept the friction tax – or you build something that will not survive contact with reality at the banking and regulation level today.

Conclusion

The future of payments will not be won by shaving milliseconds off an API call. It will be won by eliminating the workflow failure modes that make bank payments feel unreliable: context switching, timeouts, fragile redirects, and unclear confirmation loops.

Human-in-the-loop agentic payments is not a compromise. It’s a concept that is deeply informed by the realities of the systems and frameworks that exist today.