Subledgers
The CR system offers the ability to create subledgers instantly and on-demand. A subledger can be linked to any existing deposit account, also known as the master account.
Subledger API Endpoints
In subledger API endpoints, subaccounts
is used instead of subledgers. For instance, GET/v1/dda/subaccounts
.
In the CR system, subledgers are a first class citizen. All transactions first go through a subledger, followed by the master account. Each master account has what is called an implicit subledger, which is automatically created and maintained. The implicit subledger accounts for the portion of the balance which is directly attributed to the master account's activity. The CR system does this by giving it the same account number as the master.
With the use of an implicit subledger, master account subledgers always sum to the balance of the master account. It is virtually impossible for your master account and subledger to be out of balance.
The master account implicit balance can go negative. This would occur in situations where more funds are attributed to other subledgers than the master account directly. It is the responsibility of the partner to maintain and reconcile the subledger system.
Real-Time Subledger
The subledger and master account balances are updated atomically and never out of sync. Funds posted to a subaccount are immediately available
Subledger account numbers
Like all account numbers, subledger account numbers are globally unique within the bank. Subledger numbers are 12 digits and follow this format:
3 [10 digit random number] [check digit]
All subledger account numbers in COS start with 3.
In theory, it is possible to create millions of sub accounts under a single master account.
Account Check Digit
All accounts use a luhn check digit to validate the other digits in the account number. For more information on the luhn algorithm go here.
Example of a subledger

-
A checking account is opened with an initial deposit of $500. An implicit subledger with the same number is created and is tracking the balance of the master.
Master Account # Subledger Account # Balance 2000012345
--
$500
2000012345 (Implicit)
$500
-
Next, two subledgers are created at the request of the partner:
Master Account # Subledger Account # Balance 2000012345
--
$500
2000012345 (Implicit)
$500
300007770001
$0
300007770002
$0
-
A wire for $500 is sent to each of the subledgers:
Master Account # Subledger Account # Balance 2000012345
--
$1500
2000012345 (Implicit)
$500
300007770001
$500
300007770002
$500
-
$1,000 is pulled from the master account directly:
Master Account # Subledger Account # Balance 2000012345
--
$500
2000012345 (Implicit)
($500)
300007770001
$500
300007770002
$500
The implicit subledger is now negative but the sum of the subledger still correctly reflects the master account balance.
Best practiceTransfer subledger funds to the master account before spending the money. The implicit balance should match the master balance.
Subledger types

Passthrough subledgers
With passthrough subledger configuration, the master account balance is the true representation of value in the account when determining funds availability for transactions. Thus only the master account balance will be used in transaction decisions. The master account balance is not dependent on subledgers, and the master account balance can move above or below the aggregate value reflected in the subledger balances. Thus the sub ledger balance is ignored.
An individual subledger balance in this configuration can go negative, as can the implicit subledger balance. However, the master account must have a sufficient balance for a withdrawal to post.
Usually, with a passthrough configuration the partner maintains a ledger with end-user (customer) balances on its own systems. The partner can also maintain a customer ledger at CR with the passthrough configuration. However, that requires that the partner actively maintain a true balance by transferring funds to and from the master and subledgers as needed (for example, a withdrawal from the master account requires a corresponding transfer from a subledger to the master account).
For this reason, passthrough subledgers aren’t an optimal way to maintain a balance of all their customers’ dollars when compared to the direct subledger configuration.
Withdrawing funds with passthrough subledgers
With passthrough subledgers, partners can withdraw funds from the master account or directly from a subledger.
Withdrawing funds from master account (passthrough)
When funds are withdrawn from the master account, they are debited from the implicit subledger (which represents the true balance), as well as from the master account. This is because in the passthrough configuration the aggregate value in the non-implicit subledgers does not equal the total balance in the master account.
Partners can withdraw funds from the master account without first transferring funds from a subledger to the master account. In this case, the subledger will represent a balance which is not a true representation of available funds.
Withdrawing funds from subledger account (passthrough)
If a partner wants to withdraw funds directly from the subledger, there is a corresponding debit to the implicit subledger. If the master account is designated in the API as the account to withdraw from, funds will be debited from the master account and the implicit subledger. If a subledger is used in your transaction or payment request, the CR system will transact on the master by that amount.
Depositing funds with passthrough
In passthrough, when funds are deposited they are credited to the designated subledger, the implicit subledger, and the master ledger.
Direct subledgers
Under a direct ledger configuration the aggregate subledger balance will be used in transaction decisions. The implicit subledger cannot go negative, and neither can any of the individual sub ledger balances.
With direct subledgers, the aggregate sub ledger balance must equal the value in the master account. If the partner wishes to withdraw funds from the master account, the funds must be transferred from a sub ledger account to the master account.
With a direct subledger, when a partner makes a withdrawal, funds are debited from the subledger. Funds cannot be withdrawn from the master account without transferring them first from the subledger to the master account.
Passthrough vs. direct subledgers
Regardless of what type of subledger is used, the balance of the subledgers including the implicit subledger add up to the master account balance.
For direct subledgers, the implicit subledger is only dealing with funds coming in and out of the master. The implicit subledger doesn’t float to balance the subledgers with the master as it does with passthrough subledgers. With direct, if the master account is funded directly, the implicit subledger will reflect that value. The rest of the value is in the other subledgers.
For instance, with direct, if a master account has 3 subledgers with $100 each and the implicit balance is at $0, the master will say $300. If $100 is deposited to the master account directly, then the implicit subledger will have a balance of $100, and the account will have a total balance of $400. If $400 was to then be withdrawn from the master, there would need to be a transfer of $300 ($100 from each subledger) to the master.
With a passthrough configuration, if the master account balance is $300, then $300 is withdrawn from the master without any corresponding debits from the subledgers.
With both passthrough and direct subledger configurations, all subledgers + implicit subledger = funds availability (master). The difference is that with a passthrough configuration, the implicit subledger and individual subledgers can be negative, whereas with direct configuration they cannot.
Conclusion
Passthrough is generally better for situations where a partner manages end-user deposits in multiple banks. For instance, a partner can manage customer funds at CR and two other banks, where the aggregate customer funds total $3 million, with 10 customers. With passthrough subledgers, there is no need for partners to specify which customer dollar is held in which subledger. With direct subledgers, it’s more tricky, because partners need to not only consider how much their deposit balance is at CR in general, but how much they have allocated for each of their customers in subledgers.
A direct ledger system can be more difficult to manage, since in order to withdraw funds from the master account, the funds must be transferred from its subledger accounts to the implicit master account. For this reason, it is recommended to consider the use case and configure in a way that will best serve your needs.
Passthrough | Key Features | Direct |
---|---|---|
|
Instantaneous rollup of transactions to the master account balance |
|
|
Fully routable on all payment rails (i.e. ACH, Wires, RTP, etc.) |
|
|
Supports webhooks on subledger events (such as inbound transactions) |
|
|
Reflects balance of transactions cleared against account |
|
|
Subledger can carry a negative balance |
⮿ |
|
Will allow transactions to clear against subledger when balance < $0(as long as the master account has sufficient funds) |
⮿ |
⮿ |
Best for model where funds availability is managed at the subledger level |
|
|
Best for model where funds availability is managed outside of subledger with need for visibility and efficiency of transactional flows with co-mingled funds |
⮿ |
Opening subledgers

The only information required to open a sub ledger is the master account number and Title field. The Title is typically set to the name of the partner. Subledgers also support a beneficiary profile for storing additional data such as the name and address associated with the subledger. Your Integration manager will assist you with any questions related to the data used to populate these fields, as they can vary by use case and program.
Once opened, the subledger is ready within a few seconds.
Open Subledger Request
POST /core/v1/dda/subaccounts
{
"masterAccountNumber": "2001231234",
"title": "Acme Co",
"beneficiary": {
"referenceId": "ABC789",
"entityName": "Acme Co",
"streetAddress1": "400 Business Street",
"streetAddress2": "Suite 123",
"city": "New York",
"state": "NY",
"postalCode": "10025",
"countryCode": "US",
"phoneNumber": "2015551234",
"emailAddress": "acme@test.com",
"notes": "Testing 123"
}
}
General Ledgers
General Ledger (GL) accounts are internal accounts used for accounting purposes for internal reconciliation Being sure that all the numbers add up as they should and that we know where all the funds are.. COS processes each transaction through a GL account. A GL account must reconcile to zero (0) at the end of the day.
Although GL accounts are meant for CR-partner reconciliation, there are times when you might want to open a GL account for external purposes. For example, if you handle payroll deposits for a customer, you may need to overdraw on an account to be able to send salaries to the customers before the employer’s funds have been deposited into your account. A regular account can’t be overdrawn, but this GL can serve as the account that can be overdrawn.
Transactions
A transaction Moving funds from one account to another in COS always involves a debit of one account and a credit of another account, completed as a single atomic (simple) operation. Both sides of the transaction must happen for it to be considered completed. If, for example, the debit account does not have enough money to cover the transaction, the credit operation will not complete.
This makes sure that accounts are never out of balance and makes tracking where the money is much easier.
Account activity
Similar to transactions, account activity tracks money movement for a given account. However, unlike transactions, an activity record is linked to exactly one account. So every transaction creates two account activity records. Account activity records also keep track of more than just moving the money from one account to another.
New activity records start with a status of Pending. They stay pending until the posting day closes. At this point during the settlement process, all the account activity records for each account are listed in a new order, credits before debits. COS assigns a posting sequence number to each account activity record a posting sequence number assigned, inserts the running balances, and changes the status Posted. Once this is done, the activity is considered final and is not updated anymore.
Memo posts
You can think of a memo post as a temporary transaction. It tells the system something about the account—usually that some money will be coming in or going out. A memo post is one sided, and may or may not affect the account available balance. A memo post might stay on an account for many days. When it's not needed anymore it falls off and, if necessary, the information in it becomes a permanent transaction.
For example, when you pay for gas with a debit card, COS puts a memo post on your account until the transaction completes. When the charge is captured and finalized, the memo post falls off and is converted to a transaction showing the actual amount spent at the gas station.
An example of an "informational" memo post is with an inbound ACH credit. When CR receives an instruction from the Federal Reserve about an inbound ACH credit, we put a memo post on the account right away even though the effective date of the actual transfer might not be until the following day. The job of this memo post is to tell the account holder that there is going to be some change to their account in the future.
Posting exceptions
A posting exception is like an account activity record, except it only happens when one side of a transaction fails authorization. For example, if the debit side of a transaction fails due to insufficient funds in the account, COS creates a posting exception record on that account. COS does not put a posting exception on the credit side of the transaction because it did not fail in this example.
Availability schedules
Certain credit transactions post with an availability schedule. These schedules give instructions about the amount of the full transaction that will be available on each day after posting. These days until all the funds are available are also called the clearing window.The schedule appears on both the transaction and account activity records. It appears as a array (list) of dollar amounts, where each element of the array represents a posting day.
For example, the following illustrates how an ACH pull transaction may look with a 2-day clearing schedule (lines 15-18):
{
"id": "e25ff690-be93-469f-9915-aa9a011defbf",
"transactionId": "c93978d3-3451-40a0-be01-aa9a011dec98",
"traceNumber": "T192111321017433A",
"status": "Pending",
"transactionType": "Credit",
"activityType": "External",
"source": "Transaction",
"masterAccountNumber": "2058112745",
"subAccountNumber": "2058112745",
"transactionCode": "Outgoing ACH",
"description": "TEST ACH PULL PPD ID: 123 REF: A211P3HVG7KI",
"rail": "Ach",
"railId": "payment/eec1b00b-fcaf-4e91-a894-aa9a011d9366",
"schedule": [
0,
0,
2700
],
"isClearing": true,
"amount": 2700,
"productId": "3c6d97f2-2666-44d9-b25d-a9a800d6c59d",
"partnerId": "d6b4c661-b38a-46a3-8963-a9a40131eacf",
"postingDate": "2019-07-30T00:00:00-04:00",
"executedAt": "2019-07-30T13:21:01-04:00",
"createdAt": "2019-07-30T13:21:03-04:00",
"lastModifiedAt": "2019-07-30T13:21:03.7929693-04:00"
}
The ACH payment is for $27.00 total. The schedule
attribute shows that $0 will be available immediately on day 1 and that also nothing will be available on day 2. On day 3 the full $27.00 is available. Items such as checks generally make partial funds available each day while the item clears.
Money amounts in API calls and responses are written without a period between the dollars and the cents.
In addition to the schedule
attribute, for convenience the response includes an isClearing
flag to show whether the item is still within the clearing window. In the above example, the flag switches to false on 8/1.
The schedule is enforced via one or more account holds relating to the item in clearing, correlated by the railId
field. For example, the schedule above would be held as follows:
Hold Example
{
"id": "866d8cde-e7cf-4bf3-897b-aa9a014d9b08",
"masterAccountNumber": "2058112745",
"subAccountNumber": "2058112745",
"status": "Active",
"reason": "Availability",
"rail": "Ach",
"railId": "payment/eec1b00b-fcaf-4e91-a894-aa9a011d9366",
"amount": 2700,
"createdAt": "2019-07-30T16:14:37-04:00",
"expiresAt": "2019-07-31T00:00:00-04:00",
"partnerId": "d6b4c661-b38a-46a3-8963-a9a40131eacf",
"lastModifiedAt": "2019-07-30T16:14:37.287877-04:00"
}
Note that the hold expires at the close of business on 7/31, thus making the $27.00 available starting on the 8/1 posting day.
Interest accrual is not affected by availability schedules. Accrual will continue to start on the date of the credit regardless of any holds which are in place.
Book Transfers
A book transfer is an internal transfer of funds between two CR accounts under the same partner. The transfer is an atomic operation, which requires both a debit and credit account. The accounts can be either a master account or subledger, or any combination of the two. In this example, we transfer $100 from one account to another:
Sample Book Transfer Request
POST /core/v1/transfers
{
"debitAccountNumber": "1234567890",
"creditAccountNumber": "9999999999",
"amount": 10000
}
This transfer request will result in a transaction being created and executed:
Sample Transaction Response
{
"id": "b954ba97-31d9-4c7e-b2b0-a90b00d0669b",
"traceNumber": "T181771238453M77E",
"status": "Complete",
"debit": {
"transactionType":"Debit",
"accountType":"Deposit",
"masterAccountNumber":"1234567890",
"subAccountNumber":"1234567890",
"partnerId":"eaf67ca7-f8b8-4e7c-9bd8-a8ea00f53d64",
"productId":"f96bb66f-7afe-444d-96e8-a8eb00cfc1c9",
"result":{
"success":true,
"code":"OK"
}
},
"credit": {
"transactionType":"Credit",
"accountType":"Deposit",
"masterAccountNumber":"9999999999",
"subAccountNumber":"9999999999",
"partnerId":"eaf67ca7-f8b8-4e7c-9bd8-a8ea00f53d64",
"productId":"f96bb66f-7afe-444d-96e8-a8eb00cfc1c9",
"result": {
"success":true,
"code":"OK"
}
},
"transactionCode":"Account Transfer",
"amount":10000,
"description":"Transfer from 1234567890 to 9999999999",
"rail":"Internal",
"proposedAt":"2018-06-26T12:38:45-04:00",
"executedAt":"2018-06-26T12:38:47-04:00",
"lastModifiedAt":"2018-06-26T12:38:47.7228763-04:00"
}
Restrictions
Restrictions provide a mechanism to block certain transaction activity on an account. For example, if you wanted to block all ACH activity on an account, you could add a restriction which only applied to the ACH rail. If you then wanted to entirely freeze an account, where all activity was blocked, you could add a restriction which applied to all rails.
Partner vs. internal restrictions
As the name suggests, a Partner restriction is one that is applied by a Partner user. It is visible to all users and can be modified by both Partner and Internal users. By contrast an Internal restriction is one that is visible to Partner users, but cannot be modified or removed by them. For example, an internal Operations Team member may apply an Internal account freeze if they do not want it to be modified by the Partner.
This division between Partner restrictions and Internal restrictions also applies to holds.
Should I display restrictions to my customers?
Restrictions and holds may be sensitive in nature. Your Integration Manager (IM) will assist you with your questions on how best to handle customer support issues arising from restrictions or holds.
Restriction policies
Restriction policies are managed at the product level and define the types of transactions allowed for the program as a whole. Account level restrictions can be applied in addition to these. These policies are not managed by the partner and are configured by the Integration Team for your product.
Creating restrictions
Account restrictions work by defining a set of criteria in which the restriction applies to. For example, if we wanted to block all ACH debits over $100 to an account we would create a restriction like this:
Create Restriction Request
POST https://sandbox.crbcos.com/core/v1/dda/accounts/200012345/restrictions
{
"subAccountNumber": null,
"appliesTo": "All",
"rail": "Ach",
"transactionType": "Debit",
"otherAccountType": null,
"amountThreshold": 10000,
"transactionCode": null,
"reason": "Restricted",
"notes": "Optional notes here"
}
Null values indicate a wildcard that any value would match.
Statements
For each Deposit Account CR provides a monthly account statement. The statement contains all posted activity inclusive of the period start and end dates. The statement lists details according to the posting sequence of the account activity records.
Documents
After the statement is generated and all data has been finalized, CR might attach one or more documents to that record. A document is usually a downloadable PDF, but it could be another document type, such as a CSV file. The statement DocumentCount
field indicates the number of documents attached to that statement. Documents may take time to generate, so expect potential delays between the data portion being generated and the associated documents becoming available.
Other Features
Tax document (1099) retrieval
The IRS requires Cross River to provide account holders with an IRS Form 1099 for interest earned on their accounts equal to or greater than $10.00. The CR system aggregates earnings information across each customer's accounts to ensure that a 1099 is only generated if that customer's earnings are $10.00 or more. You can retrieve 1099 forms either by API or using COS Explorer.
Early Direct Deposit (EDD)
What is Early Direct Deposit?
Traditional direct deposit means that, for example, when an employer deposits a paycheck, the deposit is posted to the customer account on the effective date. Early Direct Deposit gives customers who receive their paycheck through direct deposit access to their funds up to 2 days earlier than traditional direct deposit. Cross River settles funds upon receipt of the ACH file from the Federal Reserve rather than waiting to release them on the effective date.
By providing Early Direct Deposit, you benefit your customers by improving their cash flows, which could enable them to avoid overdrafts, pay down debt, and generally experience less financial stress.
By meeting customer preferences for quicker access to funds, you may encourage more engagement with your services. Earlier settlement of funds may also support greater debit card usage, potentially generating increased interchange revenue.

Ensure that your customers:
-
Understand the requirements and limitations
-
Have checking or savings accounts set up with Cross River.
-
Are enrolled for direct deposit with their employers. Once Early Direct Deposit is enabled, 1 to 2 pay cycles are usually necessary before Early Direct Deposit takes effect.

-
Your customer's employer instructs their bank or payroll agency to initiate payroll payment.
-
The employer’s bank sends an ACH file to the Federal Reserve.
-
The Federal Reserve sends the ACH file to Cross River.
-
Cross River settles funds to customer’s account on the same day the ACH file is received (up to 2 days before the effective date). A memo post* is added to the available balance. On the effective date, the memo post is replaced seamlessly by a full a transfer.
-
The customer can access funds upon settlement.
*Memo posts are generally used with debit cards, meaning the available balance drops. In this case, the available balance increases.
How is Early Direct Deposit enabled?
Reach out to your Relationship Manager. Once you sign a contract addendum, COS Ops enables Early Direct Deposit for your customers.
Limitations
Be aware of the following limitations:
-
Early Direct Deposit is not guaranteed and depends on timely transfer of ACH files.
-
The customer's employer must initiate the payroll payment on time, and the employer’s bank or payroll agency must ensure delivery of ACH files to the Federal Reserve before the effective date.

Once early DD is enabled for you in the sandbox you can call the simulate API to generate an ACH that will match the EDD requirements.
Use the POST /v1/payments/simulated-inbound-originations
endpoint with these values for the following attributes:
-
serviceType
= standard -
secCode
= PPD -
description
= DIRECT DEP