Pismo now has a PRESET scheduler type for the Scheduled transfers endpoint. Currently, it is in beta and subject to change. With this type you would provide the full list of executions, each with its own due date, in a single operation. You can create uo to 60 executions at a time this way.

These executions can all be correlated to an original Open Finance consent. Open Finance in Brazil is a regulated system created by the Banco Central do Brasil (BCB) and the National Monetary Council (CMN) that lets customers safely share their financial data, products, and services across different banks, fintechs, and financial companies. It combines the Central Bank's instant payment system with Open Finance APIs to remove friction from digital, mobile, and contactless checkouts.

Pismo's solution supports Open Finance transactions originated from manual entry, DICT, QR Code and Payment initiator. New processing codes may be required (owned by pix-api).

Contact your Pismo representative before attempting to use preset in production.

Example PRESET payload:

{
  "type": "PRESET",
  "executions": [
    { "execution_datetime": "2026-01-10T12:00:00Z", "retry_datetime": "2026-01-11T12:00:00Z", "metadata": { "end_to_end_g_code": "500001" } },
    { "execution_datetime": "2026-02-10T12:00:00Z", "metadata": { "end_to_end_id": "E124..." } }
  ]
}

Once created , the executions can be listed through the List Pix scheduler executions endpoint. Because they already exist, the Get scheduled transfer endpoint does not return any data about preset executions.

Execution business rules

1. Open Finance originated transactions are identified via processing_code (carried in the execution metadata and Pismo validated.
2. At most, one execution per calendar day (UTC)
3. PRESET` schedules preserve the customer-provided end-to-end ID for every execution.
4. The platform never replaces or regenerates a supplied Open Finance end-to-end ID.
5. Each execution can be cancelled independently (via its status).
6. Cancelling one execution does not impact the remaining executions.
7. A cancelled execution does not trigger provider communication.
8. Future executions remain visible through schedule inquiry APIs; next_execution returns the smallest pending execution.
9. Recurring schedules with no end date remain supported under the existing recurring model.
10. At most one execution per calendar day (UTC), matching the ex key granularity.
11. Each scheduled execution uses a unique correlation ID (CID), since it is an idempotency key for downstream processing
12. Given a PRESET schedule with predefined end-to-end IDs, when an execution runs, then the corresponding end-to-end ID is used without modification.
13. Given a cancelled future execution, when its execution date arrives, then it is skipped and not sent to the provider, and the chain proceeds to the next pending execution.
14. Given a request to cancel a specific execution, when it succeeds, then only that execution is cancelled and all remaining executions stay pending.
15. Given a PRESET scheduled payment, when queried through the APIs, then all planned and executed executions remain correlated to the same consent context.