Endpoints for use in configuring the frontend before and after authentication.

Authentication and authorization related endpoints.

API Keys can be managed with these endpoints.

The Borrower object represents a borrower. It allows you to maintain different statuses that are associated with the same borrower. The API allows you to create, delete and update your borrowers. You can retrieve an individual borrower as well as a list of all your borrowers.

Identity objects represent various forms of identification that a borrower may have. We allow one primary identity per borrower, and any number of secondary identities. The identity sent when creating a borrower is the primary identity, and cannot be deleted/archived or changed to be a secondary identity.

This object allows you to add and manage a Borrower's contact information. A Borrower can have an "unlimited" number of contacts. However, it is important to properly create key contact objects.

Peach Borrower Portal (if used by the lender), shows the following contacts only:

EMAIL contactType=email, label=personal or work, affiliation=self, status=primary.

MOBILE PHONE contactType=phone, label=personal, affiliation=self, status=primary.

HOME PHONE contactType=phone, label=home, affiliation=self, status=secondary.

HOME ADDRESS contactType=address, label=home, affiliation=self, status=primary.

The Peach system sends notices (e.g. payment reminder) to borrowers (if configured by the lender). In order for a notice to be sent successfully, both contact object and template must exist. If a contact cannot be found, the system will not send a notice. The system will try to find the following contact objects:

Email notices: contactType=email, valid=true, affiliation=self, status=primary (if "primary" is not found, the system searches for "secondary" and then for "additional")

Text message/SMS notices: contactType=phone, valid=true, affiliation=self, receiveTextMessages=true, label=personal, status=primary (if "primary" is not found, the system searches for "secondary" and then for "additional")

This object represents a payment method (e.g. bank account, credit card, debit card, etc.) belonging to a borrower.

Explicit consent to receive certain kinds of communications.

This object allows you to add or create documents related to a borrower. There are multiple ways to use document object:

• Render a document from a Peach template. For example, loan terms or Autopay agreement.
• Upload any type of file. For example, a PDF copy of borrower's driver license.
• Documents can also be used to render a legal disclosure from Peach template.

To create a new document there are two steps:

1. Create a document descriptor.
2. Upload document content/file.

When a new document is rendered from the template you just need to complete step #1.

If a borrower is represented by a legal entity you can add the legal entity details. Normally, if a borrower is represented by a status=active legal entity we block future debt collection related communications.

A borrower verification session represents the question and response flow for an agent to verify the identity of a human who purports to be a particular borrower. For instance, upon receiving a phone call, an agent would initiate a borrower verification, ask the questions to the borrower, and enter their responses. A set of responses are either correct (thus verifying the human as the borrower) or they are incorrect.

The agent is never shown the correct answers, so privacy risks are minimized and socially engineered security attacks are mitigated.

This object represents configurations describing how new borrower verifications should behave.

This object allows you to create custom Campaigns. A Campaign is characterized by a set of rules, defined as a SQL query created in Redash and associated with the Campaign. A Campaign can be triggered at predefined intervals. For example, a Campaign can be triggered every day to add borrowers who are 30 days past due. Campaigns can also be manually triggered. When a Campaign is triggered by schedule or manually, a query is executed against the lender's replica data and returns a list of person IDs. The output is sent to the configured Contact Exporter to be written as a configurable CSV file with contact information required by auto dialers and other systems.

This object allows you to create custom Contact Exporters. The Contact Exporter defines how and where the contacts generated by the Campaign are delivered.

A bulk sender object represents a campaign worker which sends messages to the borrowers returned by a campaign's query results.

For each row returned by the campaign a message is sent via the Send endpoint.

In order for a bulk sender to function, at a minimum the campaign's query results must return at least the column borrowerId. For more details on required columns see per-InteractionSubject documentation for  Campaign run.

If no channel is specified the campaign will send to all channels with a defined template.

This object allows you to add cases to a borrower that are relevant to servicing or collections. For example, a bankruptcy case. A borrower can have multiple cases. If you enabled Compliance Guard monitoring feature, we'll create a new case every time a borrower matches to one of the external data sources we use. For example, if you monitor for active military, and we match one of your borrowers to the SCRA (https://scra.dmdc.osd.mil/scra/) database we'll create a new case with type=militaryDuty.

This object allows you to create custom case types. You then can create case instances from a case type. Peach has a predefined collection of special case types, such as bankruptcy, identityTheft, and more. You can use any of the special types as your base case type. To customize your case type you can:

• Add additional custom fields
• Add and remove automatic Do Not Interact Types
• Add custom name
• Add custom description

If you don't want to use any of the special predefined case types, then use generic as your base type.

The Smart Reviews system allows for creating reminder tasks in the Peach CRM based on certain key events or triggers. For example, a trigger could be when a borrower starts military service.

At creation time, all case types are supplied with a default smart review configuration that is disabled by default. Smart review tasks can be enabled by setting the smartReviews.enable flag.

This object allows for the management of many cases across a number of borrowers. That is to say that a supercase can create, manage, and close many cases at once.

This is particularly useful if an issue occurs which affects a large group of borrowers.

• Cases created by a supercase are called subcases
• A supercase can only manage cases it has created (i.e., NOT cases created via the /cases endpoint)

Managing "who" is affected by a supercase is an important aspect of supercases:

• A member of a supercase is one "borrower-loan" pairing.
• A population is a set of members added at once.
  • A supercase might have many populations if different members are added at different times.
  • It's useful to keep track of sets of members like this because different actions might need to be taken on different members depending on when they're added to a supercase.
  • A population's membership may be changed until it is "committed" by setting isDraft: false, at which time the memberships are locked and subcases are created.

This object allows you to block interactions on a borrower; and must be connected with a case. You can create multiple Do Not Interact instances on a borrower but only one instance on a case. There are two ways to create Do Not Interacts:

1. Manually - after a case is created, you can manually create Do Not Interact objects on any borrower case.

2. In bulk on a Supercase, on the related subcases. See Create Do Not Interact instances on all subcases for more details.

This object allows you to create custom Do Not Interact Types which will create Do Not Interact instances automatically when case conditions are met. For example, when a new bankruptcy case is initiated, the system can automatically create Do Not Interact to block debt collection related interactions for 30 calendar days.

The conditions are set in the following way. There are two triggers and one condition fields that you can configure:

1. onStatus - triggered based on the case status.
2. onOutcome - triggered based on the case outcome.
3. onCondition - condition(s) based on case fields values.

You must provide at least one trigger, onStatus or onOutcome, when creating a new Do Not Interact Type object.

Few examples:

• onStatus=processing, onOutcome=null, onCondition=null - the Do Not Interact instance will be created when the case status is changed to processing.
• onStatus=completed, onOutcome=approved, onCondition=null - the Do Not Interact instance will be created when the case status is changed to completed and the outcome is approved.

Do Not Interact Types must be associated with Case Types. A Do Not Interact Type object can be associated with multiple Case Types.

This object allows you to create custom Notification Types which will create interaction instances (such as emails, text messages, etc.) automatically when case conditions are met. For example, when a new bankruptcy case is initiated, the system can automatically send an email notification and ask the borrower to provide supporting documents.

The conditions are set in the following way. There are two triggers and one condition fields that you can configure:

1. onStatus - triggered based on the case status.
2. onOutcome - triggered based on the case outcome.
3. onCondition - condition(s) based on case fields values.

You must provide at least one trigger, onStatus or onOutcome, when creating a new Notification Type object.

Few examples:

• onStatus=processing, onOutcome=null, onCondition=null - the interaction instance will be created when the case status is changed to processing.
• onStatus=completed, onOutcome=approved, onCondition=null - the interaction instance will be created when the case status is changed to completed and the outcome is approved.

Notification Types must be associated with Case Types. A Notification Type object can be associated with multiple Case Types.

Tasks are used to track work that needs to be done by agents in the CRM. Tasks are automatically assigned to agents based on configurable characteristics of the agents and the tasks.

Task-Worker Pairing Configs are used to configure the behavior of tasks in the CRM. A TWPC is used to define the rules for how tasks are assigned to agents (i.e., workers).

In order to configure a TWPC you need to understand the contents of task and worker objects. See the List Unterminated Task endpoint and the List Workers endpoint for more details.

Borrowers typically have loans. We support multiple loan types and each loan type comes with its set of federal and state compliance rules. You can maintain different statuses of a loan. A borrower can have multiple loans. A loan can belong to multiple people, but only one borrower can be defined as a mainBorrower. A loan is always created using the mainBorrower borrower identifier. Other people can be added as part of the loan details.

All loan attributes can be updated as long as the loan is in pending status. Once the loan status changes to originated attributes of atOrigination object become read only and cannot be updated.

A Loan doesn't start accruing interest until it is activated. To activate the loan, call Activate a loan. On activation the loan can use the due dates and payments schedule from the atOrigination object or the loan can be re-amortized using the activation date as the loan start date.

This object represents an installment advance (also called loan proceeds or loan disbursements). Advances should be used for installment loans of type "multiple advances". Advances can be made on Loan objects only. To clarify, Advances cannot be made on Line of Credit objects. Advances increase principal balance of a Loan. Each advance has a unique identifier.

This object represents refunds. Various situations require full or partial refunds of a loan. Depending on the refund amount and whether the borrower has made payments, a refund may also trigger a reimbursement to the borrower.

This object represents a draw. Draws can be made on Line of Credit loans only. Draws can be amortized or non-amortized. If amortized, the draw will be amortized over the selected number of periods and aligned to the Line of Credit due dates. If non-amortized, the draw is due on a due date following the current period statement creation. A draw can have different interest and promo rates from the Line of Credit. Each draw has a unique identifier, similar to a loan.

This object represents a line of credit purchase. Purchases can be made on Draw objects only. Purchases of type regular increase principal balance of a Draw. Some purchase types, such as cashBack or refund are actually reduce the principal balance of a Draw. Each purchase has a unique identifier.

This object represents the expected loan payments on due dates. Expected payments are what we expect to receive from a borrower on a specific date. Expected payments are created as a result of loan amortization. The amounts and due dates can change during lifetime of a loan. For example, a borrower might change due dates frequency from monthly to weekly and it will lower periodic payment amount.

This object represents information on the borrower's obligation for a given loan period. It also provides information on the current status of the fulfillment of the obligation vis-à-vis the amount due and the due date. The obligation is dynamically changing as a result of factors such as payments and service credits made, and the crossing over of due dates.

Payment plans are a specific type of hardship tool that can be used to create a temporary loan schedule for a borrower. Lenders can create a payment plan by specifying the paymentPlanType, numberOfPeriods and amount. After the numberOfPeriods ends, any remaining periods of the loan will be paid according to the originally scheduled recurring amount and frequency of the loan at the time when the payment plan was created.

When the agreed upon recurring payment plan amount is less than the originally scheduled payment amount, the system uses isExtendLoanDuration to ascertain whether to keep the existing loan duration or automatically extend the original loan duration.

When the agreed upon recurring payment plan amount is more than the originally scheduled recurring amount, the loan duration will be shortened to the point where the remaining balance of the loan is paid off.

Only one active payment plan is allowed at a time. Please note that creating an active payment plan will overwrite changes made to the loan schedule such as due date deferrals, change due date, and change loan terms. This is because the payment plan by design creates a new loan schedule.

If a loan is on a payment plan, other hardship tools cannot be used. Lenders must cancel the payment plan and then make any required loan modifications.

Payment plan is presently for installment only.

This object represents a Promise to Pay Plan. A Promise to Pay Plan is a group of Promise to Pay Periods— unscheduled payments that was verbally committed by a borrower. Promise to Pay Plans are defined on an account level. Promise to Pay Plans are not guaranteed payments. They are used to track verbal commitments made by borrowers.

Note: When creating or updating a Promise to Pay Plan, either pass a schedule object, or pass schedule descriptor attributes— startDate, frequency, specificDays, duration and amount. Mixing the two approaches is not allowed.

This object contains information about the fees that are charged to the loan, including draw, origination or dynamic fees, such as late fees.

This object represents the interest and promo rates of the loan. You can modify interest and promo rates at any time. If a rate is modified or added with an effective date in the past, we will recalculate loan balances retroactively and future expected payments from the effective date. If a rate is modified or added with effective date in the future, we will recalculate future expected payments only.

This object represents payments and credits. Payments represent real money that were paid back by borrowers. Credits are adjustments made on a loan. Credits lower balances similar to payments. Credits can be issued by customer service representatives or supervisors.

This object represents line of credit (e.g. credit card) or loan (e.g. personal installment) statement. Each statement is associated with one due date.

For lines of credit, statements are created one calendar day after the period end date. The number of dates between a statement creation and a due date can be configured by lenders, but are normally 14 or 21 days.

For installments, there are two options for when statements can be created:

1. One calendar day after the period end date, which is also the due date. In this case, the statement date and due date are the same.
2. A number of calendar days before the period end date. The offset (as number of calendar days) can be configured by lenders. In this case, a statement is created and sent before the period ends, which means some of the statement details are calculated based on partial period data (e.g. amount of interest accrued in the period.)

This object represents the current Autopay plan. The current Autopay plan must be canceled before creating a new plan. The autopay cadence can be aligned to due dates or can be on a different payment schedule.

This object represents current loan balances.

This object represents loan credit reporting data as it was reported to credit bureaus.

Investors associated with a loan.

Allows a loan to be assigned to a collection agency

BETA

Allows lenders to associate physical or virtual card with a loan or line of credit.

Send and receive communications like email and text messages with borrowers and their contacts. When sending and receiving communications an interaction is usually created.

The templates system is used manage templates and render content from existing templates. Templates can be used, for instance, when sending emails and text messages. Custom branding and dynamic fields can be added into templates.

Peach displays some messages as documents or UI elements. You may choose to customize the content of these messages using the templating system.

Peach automatically sends messages on your behalf. For example when autopay is enabled for a borrower a message with subject autopayEnabled is sent.

Interactions represent communications with a borrower.

Whenever Peach communicates with a borrower an interaction is recorded.

Additionally, communications taking place outside of Peach should be recorded as interactions.

Past interactions information is used by Compliance Guard to make decisions about when and how it is appropriate to communicate again with a borrower.

Compliance Guard helps ensures communications with borrowers are compliant with regulations.

Peach allows clients to bring their own/partner bank to process ACH payments. If configured, the Peach system will create NACHA files and upload them to the provided destination (SFTP). The Peach system will download NACHA return files from the same destination. Make sure you coordinate this setup with the Peach team.

NACHA requires bank accounts to be verified. If you are using Peach system to process ACH payments, borrowers have two options to verify their bank account:

1. Connect their online bank account via Plaid.
2. Trigger micro-deposits and verify amounts.

Please note the following logic of how Peach system selects payment processor for micro-deposits. A payment method is associated with a borrower object instead of a specific loan because the same method can be used to pay multiple loans.

• If you have only one loan type and one payment processor with default=true, the system will use the default=true payment processor to initiate micro-deposits.
• If you have more than one loan type and one payment processor with default=true, the system will use the default=true payment processor to initiate micro-deposits.
• If you have have more than one loan type and more than one payment processor:
  • You can associate a specific payment processor with a loan type.
  • If a borrower has one or more loans in status [pending, originated, active, frozen, accelerated, chargedOff] of ONE loan type only, the system will use that loan type's ACH payment processor for micro-deposits. If the loan type doesn't have an ACH payment processor associated, the system will use the default=true processor to initiate micro-deposits.
  • If a borrower has one or more loans in status [pending, originated, active, frozen, accelerated, chargedOff] of more than one loan type, the system will use the default=true processor to initiate micro-deposits.

BETA

Allows clients to manage configurations for card issuers.

This object represents institutional owners of loans. Investors must be created before they can be associated with loans.

This object represents a bank account belonging to an investor. Peach will settle payment proceed into that account.

Allows configuration for which fields should be included for loans or payments tapes.

Allows investors to get different loan tapes delivered to different SFTP servers.

Allows lenders to keep track of merchants associated with loans and purchases. Merchant details can be shown in the Peach Borrower Portal. The following attributes are shown to a borrower:

NAME businessName

ADDRESS address

DEPARTMENT OR CONTACT NAME primaryContactName

EMAIL primaryContactEmail

PHONE primaryContactPhone

This object represents an event. Events are sent from Peach to you. Events can be related to any object in this API.

Allows clients to manage webhooks.

The Peach webhook system will issue POST requests with the event data as JSON payload.

This utility function returns financial institution name that a routing number belongs to. This information is updated once or twice a month by the Federal Reserve Bank.

This utility function returns card details. The BIN information is provided by First Data and normally updated weekly.

This utility function is used for managing index interest rates (for example, a rate that is pegged to the prime rate of the Fed). Index Interest Rates are set at the loan type level and can be used by loans associated with the loanTypeId. Index Interest Rates are only relevant to interest rates and not relevant to promo rates.

Index Interest Rate values can be updated with a new value with an effective date in the past. When a new Index Interest Rate value is set, the previous rate end date will be set to one calendar day before the new rate's effective date. If the new rate's effective date is in the past, the Peach system will replay all Active loans (to clarify, Active loans at the time of Index Interest Rate update) with the new Index Interest Rate value and re-accrue loans' interest.

Allows lenders to keep track of different collection agencies that charged-off loans may be assigned to. This is useful when a lender assigns charged off loans to a third party debt collection agency. The Peach Borrower Portal will display the collection agency information to the borrower. The lender can continue to use Peach as the system of record / ledger for charged off loans. The lender can post any payments collected by the collection agency as isExternal=true transactions. The Peach system will waterfall the payments and update loan balances.

Errors