Issue #002 · Fintech Product Forge
Last week we talked about why blind ACH retries are a silent compliance risk.
This week we go broader - to a feature every payment product has, that almost every payment product gets wrong.
Scheduled payments. They look simple from the outside.
They are anything but.
- Gaurav
🔩 THE FORGE
The deceptive simplicity of "pay later"
Every payment product has a scheduled payments
feature. Bill Pay. Standing orders. Recurring
subscriptions. Future-dated transfers.
The user experience is simple: pick an amount,
pick a date, confirm.
The system underneath that simple experience is
where things get complicated - and where most
teams underestimate the work until they're already
in production.
Here's what actually happens when a user schedules
a payment for two weeks from today.
The instruction gets stored. A background job picks
it up on the scheduled date. The system attempts
to execute it.
Simple enough. Until you ask the next question:
what does "execute" actually mean?
The re-validation problem
Here's the part most teams miss: a scheduled
payment must be re-validated at execution time -
not just at submission time.
Think about what can change between when a user
schedules a payment and when it actually runs:
➥ Their account balance may be insufficient
➥ The destination account may have changed or closed
➥ A fraud rule that didn't exist two weeks ago
may now flag this transaction
➥ The user may have lost their account access
or been flagged for suspicious activity
➥ Regulatory requirements may have shifted
A system that validates only at submission time
is making a bet that nothing will change. In
payments, that bet loses constantly.
Re-validation at execution time isn't optional.
It's the difference between a scheduled payment
system and a reliable scheduled payment system.
Cut-off windows and the time zone trap
Scheduled payments have to contend with cut-off
windows - the times after which a payment
submitted today won't process until the next
business day.
For ACH, same-day cut-offs typically fall between
2:45pm and 4:45pm Eastern. Miss the window by
one minute and your "today" payment becomes
"tomorrow."
Now add time zones.
A user in India scheduling a payment to land on
a specific US business date needs the system to
understand that their "Tuesday" and the
processor's "Tuesday" are not the same moment.
And then add bank holidays. Federal holidays in
the US. State holidays. International holidays
for cross-border payments.
A scheduled payment system that doesn't model
all of this correctly will silently deliver
payments on the wrong date - and the user won't
know until they check their statement.
Failure at execution time is a different problem
When a real-time payment fails, the user is
present. They see the error. They can retry.
When a scheduled payment fails, the user is
gone. They scheduled it and moved on. They
may not check for days.
This changes the entire failure handling design.
You need:
➥ Proactive notification at the point of failure
➥ A clear explanation of why it failed
➥ An obvious path to retry or reschedule
➥ A grace period policy - do you attempt once
and stop, or retry the next business day?
Most products figure this out after their first
wave of angry support tickets. The better
approach is to design for execution failure
before you write the scheduling logic.
The PM lesson
Scheduled payments feel like a UI feature.
Pick a date, confirm, done.
They're actually a distributed systems problem
wrapped in a simple interface.
The questions that matter aren't design questions:
How do you handle clock drift between services?
What's your retry policy when execution fails?
How do you communicate failure to a user who
has already left the screen?
What happens to scheduled payments when a user's
account is suspended mid-cycle?
These are product decisions. They need to be made
explicitly - before engineering builds the
background job, not after it's in production.
The simplest features in FinTech are often the
ones that demand the most careful design.
⚡ SIGNAL vs. NOISE
Same-Day ACH volume up 45% in 2024
The shift toward faster payments is
accelerating. For product teams, this
changes the cut-off window calculus -
more submission windows, more complexity,
more edge cases to design for.
Not a threat. A design challenge.
RTP and FedNow still not interoperable
Two instant payment networks. Neither
talks to the other. For scheduled payment
systems targeting real-time execution,
you still have to pick a rail - and your
choice affects which banks you can reach.
The unification conversation is happening.
Don't hold your breath.
🧠 PM LENS
The Scheduled Payment Design Checklist
Before your team builds a scheduled payments
feature, get answers to these questions:
AT SUBMISSION | AT EXECUTION | AT FAILURE |
|---|---|---|
What do you validate now vs. at execution? | What triggers the background job? | How does the user find out? |
What confirmation does the user receive? | What happens if the job is delayed? | How quickly are they notified? |
How do you handle scheduling during cut-off windows? | What re-validation runs at execution time? | What's the path to retry or cancel? |
What's the latest time a same-day schedule is accepted? | Who is notified if execution fails? | Is there a grace period before funds are released? |
What's the retry policy? | What goes into the audit log? |
🔗 ONE LINK WORTH YOUR TIME
Nacha's Same-Day ACH cut-off window
schedule - the authoritative reference
for submission deadlines, settlement
timing, and processing windows.
If you're designing any scheduled payment
feature that touches ACH, bookmark this.
Cut-off windows aren't an engineering
detail. They're a product constraint that
shapes your entire scheduling UX.
- Gaurav Nikumbh
Senior PM · Payments & Banking Infrastructure
Founder, TechVenture360
What's the most painful scheduled payment
bug you've ever seen or shipped?
Hit reply - the best answers become
future issues.
Enjoying this issue? Forward it to one person
who works in payments or FinTech product.
Or share the subscribe link directly: