transfers/scheduled: endpoints, cursor and scheduling

[adamdecaf]

PayGate needs to support scheduled transfers, which allow a user to provide a schedule (e.g. weekly, monthly, etc) and some metadata for initiating a transfer in the future. This is a common feature in products. We would expect normal ACH durations before amounts are posted to the impacted accounts.

Fields

• From Depository / Originator
• To Depository / Receiver
• Amount
• Schedule
• Times
• StartDate
• NextDate (optional, overrides schedule if set)
• Memo (optional)
• Status
  • values: active, completed, canceled

Computed Fields

• estimatedCutoff: calculated from the configs on each endpoint read

Schedule

• Once
• Weekly
• EveryOtherWeek
• Monthly
• Quarterly
• Yearly

---

The following fields are available to be modified:

• From Account
• Amount
• NextDate
• Frequency
• Memo
• Status (e.g. to cancel)

Payments which fall on weekends will be processed on the next business day

[wadearnold]

• This scheduling engine is based on "funding date" and not "estimated received date" - Estimated received date could be a future feature.
• We need to ensure that we are calculating the dates when the federal reserve is open.
• The schedule should support a start date and pattern. Example: Start paying $5 on May 5th, Monthly for 12 months. Payments would be paid by the 5th of each month. If the 5th of any subsequent months.
• I believe that we have to have a disclosure if there is no end to scheduled payments. We may want to require the end date or periods of payments in this first implementation.
• I would want to query all remaining payments on a schedule and on what date those payments would be sent.

[adamdecaf]

Oh so if someone has a schedule "weekly starting on the 5th" we would need to have the money posted in the receivers account on the 5th? I was thinking we would initiate the transfer on the 5th. We can send these two banking days early if that's needed.

Are we doing same-day?

We can have an endpoint to get the next N estimated payment periods. That can return a date, amount, and any other computed metadata (which I'm not sure there will be -- maybe fees)

[wadearnold]

oh my goodness I explicitly stated that the calendar was the funding date and not an estimated delivery date..... then I made an example that was for estimated delivery date. We can't have with normal ACH a guaranteed delivery date but just a funding date.

• We need to support same-day ACH in the scheduling. I am not sure if we will have to expose cutoff times. I assume no for now.

[adamdecaf]

My bad. I was confused earlier and edited my comments above. I think I'm understanding this now.

The schedule is for when we initiate the transfer and send off the ACH file.

Same day can be an additional boolean on the request.

What happens if a scheduled transfer fails to be included in a file? I'm thinking about the case where we would exceed limits. I think the status of a scheduled transfer should be updated (much like we do for Transfer objects now).

[waltrcox]

Starting thinking about scheduling as discrete objects in a former life...meaning:

• scheduler = combination of filling required fields to generate transfer and selecting date/recurrence model
• availability = scheduler is dependent on Fed schedule (days of the week, holidays) and supported cut-off times

Thus, you would have to:

• have logic for the scheduler set as by the customer with the dependency on the availability
• meaning we'll never generate a file that falls outside of the availability
• availability is independent since its subject to ODFI (cut-off windows supported) and can change over time
• scheduler is also a function outside of ACH - meaning it will be used for all other functions that require delivery to a trusted third party (1099's, wires, etc.) and thus may have a different availability tied to it (wires availability vs ACH vs...)

there are other dependencies you can build into the scheduler:

• account funded status - meaning scheduler cannot be called until funds are available, conversely scheduler won't run without sufficient funds
• scheduled confirmation - moov customer "confirms" before file is generated and sent (for debits or credits)

For scope/MVP, I would suggest:

• we build for credits only at this stage (debits require a proof-of-authorization flow I want to work through with you both)