A funding rule is a standing instruction that tells PCE how to split money the moment it arrives. Instead of receiving one lump credit and reconciling the split by hand, you describe the split once, as a rule, and PCE applies it automatically to every matching inbound payment.

Funding rules act on the money you collect. When an inbound ACH, wire, check, or MoneyGram payment lands, PCE checks the active rules for the receiving customer and, when one matches, moves the configured share of the funds into the target accounts. A rule answers three business questions:

• Who does this apply to? (which customers or segments, the association)
• When does it apply? (which method, and any transaction condition)
• How are the funds split? (the target accounts, shares, and order, the action)

For the full field list, jump to the Request reference.

The funding rule lifecycle

A funding rule has a simple lifecycle of its own, separate from the transactions it acts on. You set it up once, it stays ACTIVE and applies to every matching deposit, and you retire it when it's no longer needed.

stateDiagram-v2
    direction LR
    [*] --> ACTIVE: Set up funding rule
    ACTIVE --> ACTIVE: Applies to every matching inbound payment
    ACTIVE --> INACTIVE: Retire
    INACTIVE --> [*]
    note right of ACTIVE
        Live from creation.
        Splits matching funds automatically.
    end note
    note right of INACTIVE
        Retired. Kept on record for
        reporting, no longer applied.
    end note

1. Set up the rule. A Program Manager defines the rule, its method, target customers, conditions, and the split actions. It's live immediately in ACTIVE status; there is no separate activation step.
2. It applies automatically. For as long as it's ACTIVE, every inbound payment that matches its association and condition is split per the rule, no per-transaction call required.
3. Retire when done. A Program Manager retires the rule to move it to INACTIVE. It stops applying but stays on record for audit and reporting. Retiring is one-way; set up a new rule to resume splitting.

How a rule splits inbound funds

The rule does its work at collection time, on the transaction lifecycle you already know. When a payment settles, PCE evaluates the receiving customer's active rules and applies the first match.

sequenceDiagram
    participant Payer
    participant PCE
    participant Rules as Active funding rules
    participant Accounts as Target accounts
    Payer->>PCE: Inbound payment (ACH / WIRE / CHECK / MONEYGRAM)
    PCE->>Rules: Match on method + association + condition
    Rules-->>PCE: Matching rule (with split actions)
    PCE->>Accounts: Split funds per action, in order
    Note over PCE,Accounts: Program Manager, Program Affiliate,<br/>or Customer accounts by tag

Funds are moved into each target account in the order you define, as a percentage of the total amount or a fixed amount, and routed to the Program Manager, a Program Affiliate, or the customer.

What you can express in a rule

These are the levers a funding rule gives you. Every scenario below is just a different combination of them.

Set up a funding rule

Setting up a rule puts an automatic split in place: describe it once and PCE applies it to every matching inbound payment from then on. A rule is live the moment you set it up, it enters ACTIVE status and begins applying immediately.

Make a POST request to /v1/fundingRule. On success the API returns 201 Created and the rule is active.

Set up your first rule

The quickest way to see it work: route 100% of a single inbound method into one account. This is the smallest valid rule, one method and one action.

POST /v1/fundingRule

{
    "name": "Wire to operating",
    "method": ["WIRE"],
    "transactionComponent": "TOTAL_AMOUNT",
    "action": [
        {
            "order": 1,
            "transferTo": "PROGRAM_MANAGER",
            "percentage": "100.00",
            "account": { "tag": "operating" }
        }
    ]
}

The rule is created ACTIVE and, from that point, every inbound wire for the matching customer is routed to the Program Manager's operating account. The full set of fields is in the Request reference; the scenarios below build on this shape.

Scenarios

Every funding rule follows the same shape: pick a method, optionally narrow who it applies to with association and when with condition, then describe the split in action. The scenarios below cover the common business patterns end to end.

Scenario 1: Split an ACH deposit across accounts

(percentage split, targeted at a customer segment)

Use this when an inbound ACH deposit should be divided, for example a fee to the Program Manager and the balance to a trust account, but only for a specific segment of customers. Here the rule applies only to BUSINESS customers enrolled in Alabama or Alaska: 20% of the total is routed to the fee account first, then 80% to the Trust account.

Request

POST /v1/fundingRule

{
    "externalId": "ET23353323",
    "name": "ACH Split Rule",
    "method": ["ACH"],
    "transactionComponent": "TOTAL_AMOUNT",
    "isOverridable": true,
    "isRecoupable": false,
    "association": [
        {
            "key": "CUSTOMER_ENROLLED_STATE",
            "value": ["AL", "AK"],
            "operator": "in"
        },
        {
            "key": "CUSTOMER_TYPE",
            "value": ["BUSINESS"],
            "operator": "in"
        }
    ],
    "action": [
        {
            "account": { "tag": "fee" },
            "percentage": "20.00",
            "order": 1,
            "transferTo": "PROGRAM_MANAGER"
        },
        {
            "account": { "tag": "Trust" },
            "percentage": "80.00",
            "order": 2,
            "transferTo": "PROGRAM_MANAGER"
        }
    ]
}

Response

201 Created. The rule is ACTIVE; every matching inbound ACH deposit is now split 20/80 in the defined order.

Scenario 2: Route a full wire deposit to one account

(single action, 100%)

Use this when there's no split to make, you just want every inbound wire to land in a designated account. There's no association, so the rule applies to all of the customer's inbound wires; isOverridable: false prevents an inheriting customer or partner from replacing it.

Request

POST /v1/fundingRule

{
    "externalId": "WIRE-RULE-001",
    "name": "Wire Transfer Split",
    "method": ["WIRE"],
    "transactionComponent": "TOTAL_AMOUNT",
    "isOverridable": false,
    "action": [
        {
            "account": { "tag": "operating" },
            "percentage": "100.00",
            "order": 1,
            "transferTo": "PROGRAM_MANAGER"
        }
    ]
}

Response

201 Created. Every matching inbound wire is routed in full to the Program Manager's operating account.

Request reference

The complete set of fields for the set-up request. The scenarios above use subsets of these. See Attributes for the full field reference and allowed values.

Review, find & retire your rules

Once a rule is live, you review a single rule, search across many, or retire one you no longer need. Full request and response payloads for each endpoint are in the API Reference; the essentials are below.

Review a rule

Review a rule to confirm exactly how it splits money, after setup, or while tracing where an inbound deposit went. Make a GET request to /v1/fundingRule/id/{id} (or /v1/fundingRule/externalId/{externalId}). Use externalId when you track rules by your own reference.

GET /v1/fundingRule/id/{id}
GET /v1/fundingRule/externalId/{externalId}

The 200 OK response returns the rule's full configuration, its method, association, condition, action, and current status. Read status to confirm it's still ACTIVE, and the action array to see the exact split.

{
    "resourceName": "fundingRule",
    "id": 754,
    "externalId": "ET23353323",
    "name": "ACH Split Rule",
    "method": ["ACH"],
    "transactionComponent": "TOTAL_AMOUNT",
    "ownership": "SELF",
    "action": [
        { "account": { "tag": "fee" }, "percentage": "20.00", "order": 1, "transferTo": "PROGRAM_MANAGER" },
        { "account": { "tag": "Trust" }, "percentage": "80.00", "order": 2, "transferTo": "PROGRAM_MANAGER" }
    ],
    "status": "ACTIVE",
    "statusDate": "07/24/2026"
}

Find & audit rules

To see the bigger picture, search rules by criteria: a filtered, paginated search you use to audit what's live, confirm which rules are ACTIVE, reconcile by your own externalId, or review recent changes by date. Make a POST request to /v1/fundingRule/list.

POST /v1/fundingRule/list

{
    "pageNumber": 1,
    "pageSize": 25,
    "sortOptions": { "sortBy": "lastUpdatedOn", "sortOrder": "desc" },
    "criteria": {
        "filters": [
            { "operator": "eq", "key": "status", "values": ["ACTIVE"] }
        ]
    }
}

Pass one or more conditions in criteria.filters[]; each is a key, an operator, and one or more values.

Sort by id, createdOn, or lastUpdatedOn with sortOrder asc or desc. The response echoes totalCount, returnedCount, pageNumber, offset (the ID of the last record returned), and hasMore so you can page through results.

Retire a rule

Retire a rule when it should no longer split incoming funds, the split has changed, a program wound down, or you're replacing it. Only a Program Manager can retire a rule, and only rules currently in ACTIVE status. Make a POST request to /v1/fundingRule/id/{id}/deactivate (or /externalId/{externalId}/deactivate) with an empty body.

POST /v1/fundingRule/id/14/deactivate

{}

On success the API returns 204 No Content, the rule moves to INACTIVE, and it stops applying to incoming funds. Retiring is one-way; an INACTIVE rule can't be reactivated, so set up a new rule to resume splitting.

Inheritance and ownership

Funding rules can cascade down your program hierarchy:

• A Program Manager can create rules on the customers under them to split incoming funds among their own, their partner's, or any of their customers' Passport accounts.
• Customers can inherit funding rules from their Program Manager or a partner.
• An inherited rule can be overridden at a lower level only when the creator marks it as overridable (isOverridable: true).

The ownership attribute records who owns a rule. A value of SELF means the rule was created by the user themselves.

Attributes

Statuses

Business validations

• Program Managers can create funding rules on the customers under them to split incoming funds among their own, their partner's, or any of their customers' Passport accounts.
• A funding rule is always created in ACTIVE status.
• Program Managers can retire a rule to mark it INACTIVE.
• Customers can inherit funding rules from their Program Manager or a partner. An inherited rule is overridable only when the creator allows it (isOverridable: true).

See also

• Move money: initiate payouts, collections, and transfers that funding rules act on
• Collect: pull inbound funds that a funding rule can split
• Accounts: the Passport Accounts funds are split into
• Error Codes and Messages: reason and return codes when an operation fails