Challenges Businesses Face With Instant Payments

Struggling with instant payments adoption despite having the technology in place? Many financial institutions are finding themselves in the same boat. While faster payments rails are live and ready, corporate client adoption is still lagging behind expectations. ✨ In my experience, making instant payments work has a lot more to do with understanding people—organizational habits, change fatigue, trust—than with plugging in new tech. Having partnered with a range of FIs on this exact challenge, I see change management and internal inertia slow things down long after the technical pieces are in place. From what I’m seeing, here’s what’s actually moving the needle: 🌟 💵 Zero in on business cases that speak directly to actual pain points. Companies invest when there’s visible ROI—think: better cash flow insights, happier customers, or standing out from competitors. Vague promises about “real-time” aren’t enough to get buy-in. 💻 Make sure instant payments are woven into the tools people already use, especially ERP systems. When it becomes truly part of the workflow—not just another payment option—adoption follows naturally. 💸 Remove as much friction from the user experience as possible. If instant payments don’t feel easier than the old way, there’s no reason for teams to switch. Simplicity is the tipping point for behavioral change. If you’ve worked to drive instant payments adoption, I’m genuinely curious: have you prioritized the technology or the business value in your approach? Would love to hear your perspective. ❄️ #paymentselsa #fasterpayments #instantpayments #fintech #innovation

The Problem With U.S. RTP, That CANT Be Solved By Tech The U.S. banking system stands at a crossroads in its modernization journey, particularly regarding real-time payment systems like FedNow and RTP (Real-Time Payments). While these systems promise to revolutionize the speed of transactions, their current implementation faces significant challenges that limit their practical utility for many common use cases. One of the primary limitations of both FedNow and RTP is their lack of support for pull/debit flows, which are crucial for subscription billing and recurring payments. This gap in functionality represents a significant barrier to adoption, particularly for businesses that rely on automated billing systems. The industry's proposed solution comes in the form of Request for Payment (RfP), a mechanism that essentially works as a "request to push" rather than a traditional pull transaction. This approach could potentially eliminate the problematic aspects of ACH chargebacks while maintaining necessary payment functionality. The system would allow for both one-time and recurring push payments, initiated through an authorization request from the payment recipient. Currently, RfP implementation through the RTP network is operational but limited in scope. It primarily functions within restricted bank pairings, such as "Bank X corporate account asking a Bank X retail account to authorize a push. The irrevocable nature of these transactions makes them particularly attractive for specific use cases, such as payroll companies debiting employer accounts, as it eliminates the risk associated with employee payouts. "The role of stablecoins in this ecosystem appears limited, at least for domestic transactions. The fundamental issue isn't about moving money faster – FedNow is essentially a real-time ledger update. The current system's delays often stem from banks' intentional holding of funds to earn overnight returns, a practice tied to federal monetary policy objectives" - Beto Garcia, Balam SWIFT is already working to implement RfP solutions, focusing on use cases such as instant deposits (A2A) and bill pay (B2B). These applications aim to eliminate ACH return risk while supporting various permitted use cases, including consumer bill pay and payroll. However, technical capability often isn't the limiting factor. One can argue that money could have been real-time for a long time now. Instead, the challenges lie in the complex interplay of institutional interests, regulatory frameworks, and existing business models that characterize the banking sector. Moving forward, the success of real-time payment systems will likely depend on a combination of regulatory pressure, bank cooperation, and market demand. While the Fed support for these initiatives may help drive adoption, the banking industry's eventual embrace of comprehensive real-time payment capabilities will determine the pace and scope of this transformation in US financial services.

More notes from Tuesday's Faster Payments Council Member's meeting. These ones on Instant Payment Use Cases as shared by Glenn Wheeler, John Drechny Eralda Hasani, CTP, AAP, and Kelly Lewis Banking * Instant funding for broker/dealer * Instant withdrawals for clients * Instant investment of funds (vs 2 day wait) * Internal use by AP to pay vendors (goal of never having to issue a check) Off-cycle payroll * Bonuses * Reimbursements * Termination pay (lots of state labor laws mandate employees paid on day of departure, and many companies don't have an accounting person to handle this, so this is a big pain for unplanned departures) Other use cases * When finality of payment is important (ex. delivery of product, and payment must be given at time of delivery) * Recurring payments (particularly in situations where customers are on again and off again) * "events" in world that may prevent delivery in world if not paid instantly * Home improvement services "in home" where services need to be paid for while on site Hurdles to adoption * Clients that go through multiple mergers and are dealing with many systems and dealing with legacy systems challenging * Clients don't want to _pay_ faster, they want to _collect_ faster (instant payments allow you to time the funds, so that you have control over when the funds get out) * Collection of funds, this needs to happen earlier/first, so these funds can be turned around and disbursed * Merchants accepting a payment don't want to turn around and ask for another payment method if it doesn't go through, and they don't want to integrate to 4 different systems to accept payments * Merchants need to understand which payments are "final final" and which are being routed