The bank id of bank associated with the routing number.

Name of bank associated with the routing number.

Formatted timestamp (YYYY-MM-DD HH:MM:SS) determining when the enrollment was created.

ABA compliant routing number for the enrollment bank account.

Formated timestamp (YYYY-MM-DD HH:MM:SS) determining when the party was created.

Current status of the party: ok, on_hold. A party is ok if it has passed trice compliance checks. Some on_hold parties may initially show as ok but then change to on_hold.

ok on_hold

ABA compliant account number for receiving credit transfers.

Formatted timestamp (YYYY-MM-DD HH:MM:SS) determining when the account was created.

Email address (RFC 822 characters).

Current status of the account: ok, on_hold. An account is ok if it has passed trice compliance checks. Some on_hold accounts may initially show as ok but then change to on_hold.

ok on_hold

Formatted timestamp (YYYY-MM-DD HH:MM:SS) determining when the presentment was created.

Current status of the presentment: pending, reviewed, approved, denied, or on_hold. A presentment is pending until it is submitted to the review team, when it becomes reviewed. The status then changes to approved or denied if the presentment goes through (within 1 business day). Some on_hold presentments may initially show as approved but then change to on_hold.

pending reviewed approved denied on_hold

The RTP use case for the presentment: business_to_business, account_to_account, bill_pay, down_payment, security_deposit, final_payment, or down_or_final_payment.

A business_to_business use case must must have a business purpose for both the RfP sender and RfP receiver. A business purpose is a purpose that is not related to any personal, family, or household matter. Hence, so long as an RFP is not related to any personal, family, or household matter for the RfP sender or RfP receiver, the RfP sender and/or RfP receiver can be an unincorporated business or sole proprietor. For the avoidance of doubt, the purchase of goods or services for a personal, family, or household purpose is not a business purpose even if the goods or services are sold by a business.

An account_to_account use case is where a payment sent in response to the RFP results in a transfer between asset accounts that are both owned by the same person.

A bill_pay use case is seeking payment for a recurring consumer service or financial obligation or seeking payment for a non-recurring consumer service that is performed and paid for at a consumer home, such as lawn care, house cleaning, or repairs. For purposes of interpretation recurring means that payment is owed on at least a quarterly basis and that the service or financial obligation is expected to continue on an ongoing and predetermined basis for at least a year.

A down_payment use case is an initial payment owed for a financial obligation that will involve multiple payments such as rent, an installment loan, or a mortgage.

A security_deposit use case is an initial deposit at the time of opening a new deposit account or a deposit amount owed for a financial obligation that will involve multiple payments such as rent, an installment loan, or a mortgage.

A final_payment use case is a payment that fully pays the outstanding balance or amount owed for a financial obligation that involved multiple payments such as rent, an installment loan, or a mortgage.

A down_or_final_payment use case is a payment that either an initial payment owed for a financial obligation that will involve multiple payments or fully pays the outstanding balance or amount owed for a financial obligation that involved multiple payments such as rent, an installment loan, or a mortgage.

business_to_business account_to_account bill_pay down_payment security_deposit final_payment down_or_final_payment

A detailed description of the intended use case.

Formatted timestamp (YYYY-MM-DD HH:MM:SS) determining when the real time payment transfer was created.

Current status of the real time payment transfer: created, rejected, processing, failed, timed_out, finalizing, completed or returned.

An outbound credit transfer is: created if pre-checks are passed. Pre-checks may determine the transaction is rejected. When the transaction is sent to the network it is then processing. If the transaction fails network checks it will become failed. If the receiving participant failed to provide a response within the network SLA it will become timed_out. A transaction will be finalizing if the receiving financial institution accepts the transaction and then become completed when the funds are posted to the recipient. The status is set to returned if the transfer was returned.

An inbound credit transfer is: created when an incoming credit transfer is received from the network. It is rejected if Trice rejected the transaction. The transaction is processing when the accepted transaction is awaiting confirmation from the network. If the transaction fails network checks it will become failed. If the network does not receive a response from Trice within the network SLA it will become timed_out. A transaction will then be finalizing until it becomes completed and the funds are posted to the recipient. The status is set to returned if the transfer was returned.

created rejected processing failed timed_out finalizing completed returned

The type of credit transfer: outbound, inbound, outbound_from_rfp, or inbound_from_rfp. A transfer is outbound when sent from the account to an external party. A transfer is inbound when received by an account from an external party. A transfer is inbound_from_rfp if it was inbound as a result of a previous request for payment. A transfer is outbound_from_rfp if it was outbound as a result of a previous request for payment.

outbound inbound inbound_from_rfp outbound_from_rfp

ABA compliant account number for receiving credit transfers.

Formatted timestamp (YYYY-MM-DD HH:MM:SS) determining when the account was created.

Email address (RFC 822 characters).

Current status of the account: ok, on_hold. An account is ok if it has passed trice compliance checks. Some on_hold accounts may initially show as ok but then change to on_hold.

ok on_hold

Formatted timestamp (YYYY-MM-DD HH:MM:SS) determining when state data was entered.

Formated timestamp (YYYY-MM-DD HH:MM:SS) determining when the party was created.

Current status of the party: ok, on_hold. A party is ok if it has passed trice compliance checks. Some on_hold parties may initially show as ok but then change to on_hold.

ok on_hold

Formated timestamp (YYYY-MM-DD HH:MM:SS) determining when the party was created.

Current status of the party: ok, on_hold. A party is ok if it has passed trice compliance checks. Some on_hold parties may initially show as ok but then change to on_hold.

ok on_hold