# Update migration period LOC data

Endpoint: PUT /people/{personId}/loans/{loanId}/migration/period
Version: 2025-03-26
Security: oauth2, bearerAuth, apiKeyHeader

## Path parameters:

  - `personId` (string, required)
    A Borrower's unique identifier, tied to a person or a business. Can be Peach or a lender's external identifier.

  - `loanId` (string, required)
    The unique identifier of the Loan we wish to retrieve. Can be
Peach or lender's external identifier.

## Request fields (application/json):

  - `balances` (object)
    The balances passed here should be as of the "migration cutoff date" after the most recent statement was generated in your legal system.
For example:
- Migration period:
  - startDate: Aug 1, 2024
  - endDate: Aug 31, 2024
  - statementDate: Sep 1, 2024
  - dueDate: Sep 22, 2024
- Previous period (also called "past period"):
  - startDate: Jul 1, 2024
  - endDate: Jul 31, 2024
  - statementDate: Aug 1, 2024
  - dueDate: Aug 22, 2024
- Notes:
  - The balances should be as of Aug 1, 2024 after the statement was generated on Aug 1, 2024.

Do not double-count fees: a fee you charge on the LOC or a regular (non-static) draw that it belongs to with a charge date on or after the "migration cutoff date" writes itself to the ledger. For any such fee, either include its amount in these balances OR charge it through the fees endpoint; never both, or the borrower will be billed twice.

  - `balances.creditLimitAmount` (number, required)
    The line credit limit amount as of the "migration cutoff date".

  - `balances.dueBalances` (object, required)
    Due balances represent balances that are currently due.
Only fees can be passed inside the balance objects on LOC level.
All other balances are expected to be passed in the `Create migration period draw data` endpoint.

  - `balances.dueBalances.dueLateFeesAmount` (number, required)
    The late fees portion of `dueFeesAmount`.

  - `balances.dueBalances.dueOriginationFeesAmount` (number, required)
    The origination fees portion of `dueFeesAmount`.

  - `balances.nonDueBalances` (object, required)
    Non-due balances represent balances that are not yet due.
Only fees can be passed inside the balance objects on LOC level.
All other balances are expected to be passed in the `Create migration period draw data` endpoint.

  - `balances.nonDueBalances.nonDueLateFeesAmount` (number, required)
    The late fees portion of `nonDueFeesAmount`.

  - `balances.nonDueBalances.nonDueOriginationFeesAmount` (number, required)
    The origination fees portion of `nonDueFeesAmount`.

  - `balances.overdueBalances` (object, required)
    Overdue balances represent balances that are overdue.
Only fees can be passed inside the balance objects on LOC level.
All other balances are expected to be passed in the `Create migration period draw data` endpoint.

  - `balances.overdueBalances.overdueLateFeesAmount` (number, required)
    The late fees portion of `overdueFeesAmount`.

  - `balances.overdueBalances.overdueOriginationFeesAmount` (number, required)
    The origination fees portion of `overdueFeesAmount`.

  - `balances.reimbursementAmount` (number, required)
    The total amount that a lender owes to the borrower as of the "migration cutoff date".

  - `gracePeriod` (object)
    If you are not migrating past periods and the migration period is the first period of the LOC:
Don't pass the `gracePeriod` object.
If you are migrating past periods:
This is the entire LOC grace period details including all its draws.
The grace period data passed here corresponds to the previous period and not to the migration period. By the time you call this endpoint, you should have already created one or more past periods. The additional data that you pass here is only required for the previous period and not for all past periods. That's why the grace period data is part of the "Create migration period LOC data" vs "Create past periods data" endpoint.
The migration period is a "live" period in which you execute migration.
- Because the Peach system needs to know if the LOC is eligible for the grace period benefit when the migration period starts, the system
will use the `isGracePeriodEligible` passed here. If you pass `isGracePeriodEligible=true`, the system will start migration without
accruing interest in the "migration period". If you pass `isGracePeriodEligible=false`, the system will start migration with accruing
interest in the "migration period".
- On the "due date + 1" within the "migration period", the system evaluates the grace eligibility based on `fullBalanceAmount`, `fullBalanceMinusOverdueAmount` and payments made.
- If you migrate the LOC before the upcoming "due date", the system will evaluate the grace period eligibility in "live" and might revoke the benefit.
- If you migrate the LOC after the "due date", the system will evaluate the grace period eligibility as part of the "replay/migration" process.
Because of existing limitations with "replay", grace period eligibility cannot be revoked as part of the replay process. However, the replay
process can reinstate the grace period benefit (in other words, waive accrued interest from the start of the "migration period").
- Peach is responsible for generating the statement corresponding to the migration period on `migrationPeriod.statementDate` in the future.
The grace period details of the migration period will be calculated by the Peach system on `migrationPeriod.statementDate` in the future.

For example:
- Migration period:
  - startDate: Aug 1, 2024
  - endDate: Aug 31, 2024
  - statementDate: Sep 1, 2024
  - dueDate: Sep 22, 2024
- Previous period (also called "past period"):
  - startDate: Jul 1, 2024
  - endDate: Jul 31, 2024
  - statementDate: Aug 1, 2024
  - dueDate: Aug 22, 2024
Notes:
  - The grace period details that you need to pass correspond to the previous period that started on Jul 1, 2024 and ended on Jul 31, 2024.
  - The amounts and values should be as of the "migration cutoff date", Aug 1, 2024, after the statement was finalized in your legacy system.

  - `gracePeriod.fullBalanceAmount` (number, required)
    The full balance amount of the line that is eligible for grace period.

  - `gracePeriod.fullBalanceMinusOverdueAmount` (number, required)
    The full balance amount minus the overdue amount.

  - `gracePeriod.isGracePeriodEligible` (boolean)
    Was the loan eligible for grace in this period?

  - `migrationPeriod` (object)
    The migration period.
The "migration cutoff date" will be set to the `startDate` passed here. It's important to understand that `migrationPeriod.statementDate` and `migrationPeriod.dueDate` are future dates. The previous period's `dueDate` is also a future date (relative to when you execute the migration) and falls in the "migration period".
For example:
- Migration period:
  - startDate: Aug 1, 2024
  - endDate: Aug 31, 2024
  - statementDate: Sep 1, 2024
  - dueDate: Sep 22, 2024
- Previous period (also called "past period"):
  - startDate: Jul 1, 2024
  - endDate: Jul 31, 2024
  - statementDate: Aug 1, 2024
  - dueDate: Aug 22, 2024
Notes:
  - "Migration cutoff date" is Aug 1, 2024.
  - If you execute the migration on Aug 10, 2024, the "migration at date" is Aug 10.
  - Previous period's `dueDate`, Aug 22, 2024, falls in the "migration period" that starts on Aug 1, 2024 and ends on Aug 31, 2024.
  - The upcoming due date is Aug 22, 2024.
  - If you didn't complete the migration before Aug 22, 2024, you need to cancel the loan and start the process again.

  - `migrationPeriod.dueDate` (string, required)

  - `migrationPeriod.endDate` (string, required)

  - `migrationPeriod.startDate` (string, required)

  - `migrationPeriod.statementDate` (string, required)

  - `obligation` (object)
    If you are not migrating past periods and the migration period is the first period of the LOC:
Don't pass the `obligation` object.
If you are migrating past periods:
This is the LOC level obligation details only (excluding any draws).
The data passed here corresponds to the previous period and not to the migration period. By the time you call this endpoint, you should've already created one or more past periods. The additional data that you pass here is only required for the previous period and not for all past periods. That's why the additional obligation data is part of the "Create migration period LOC data" vs "Create past periods data" endpoint.
To remind, the migration period is a "live" period in which you execute migration. The obligation details of the migration period will be calculated by the Peach system. Peach is also responsible for generating the statement corresponding to the migration period on `migrationPeriod.statementDate` in the future.
For example:
- Migration period:
  - startDate: Aug 1, 2024
  - endDate: Aug 31, 2024
  - statementDate: Sep 1, 2024
  - dueDate: Sep 22, 2024
- Previous period (also called "past period"):
  - startDate: Jul 1, 2024
  - endDate: Jul 31, 2024
  - statementDate: Aug 1, 2024
  - dueDate: Aug 22, 2024
- Notes:
  - The obligation details that you need to pass correspond to the previous period that started on Jul 1, 2024 and ended on Jul 31, 2024.
  - The amounts and other values should be as of the "migration cutoff date", Aug 1, 2024, after the statement was finalized in your legacy system.

  - `obligation.migratedDaysOverdue` (integer, required)
    This represents the number of days overdue prior to the "migration cutoff" date as it appears in
the other system (not Peach). This value is normally calculated as the number of calendar
days overdue starting from the earliest overdue obligation's due date to the
"migration cutoff date". This value, once set, won't change after the migration.
This value will be prorated and added to `daysOverdue` of future obligations
(if any become overdue). The system will prorate the `migratedDaysOverdue`
dynamically as the borrower makes payments and add it to the days overdue
post "migration cutoff date".
Calculation details:
- The `migratedDaysOverdue` value will be used to prorate days overdue prior to the "migration cutoff date"
based on the paid balance of `migratedOverdueAmount` (which is set based on the `balances.overdueBalances`).
- round_down [migratedDaysOverdue x (1 - min(fulfilledAmount / migratedOverdueAmount, 1))]
- For example:
  - migratedDaysOverdue = 60
  - migratedOverdueAmount = $1000
  - Scenario 1:
    - Borrower didn't make any payment within the first 30 days after the "migration cutoff date".
    - Total days overdue:
      - 60 x (1 - min(0 / 1000, 1)) + 30 = 90
  - Scenario 2:
    - Borrower made payments in a total amount of $700 within the first 30 days after the "migration cutoff date". The line is still overdue.
    - Total days overdue:
      - 60 x (1 - min(700 / 1000, 1)) + 30 = 48

  - `obligation.migratedOverdueFromDate` (string)
    The date from which the account is overdue at the time of migration. This attribute will also
be used to calculate "Date Of First Delinquency" for credit bureaus reporting.
If `migratedDaysOverdue > 0`, then `migratedOverdueFromDate` is required.

  - `obligation.obligationAmount` (number, required)
    The remaining amount of the previous period's obligation that a borrower needs to pay on the due date that comes after "migration cutoff date". The remaining amount should be as of "migration cutoff date" vs. "migration at date".
This is the LOC level remaining obligation amount excluding any draws' obligation amounts. Only fees can be passed inside the balance objects on LOC level. All other balances are expected to be passed in the `Create migration period draw data` endpoint.
If your LOC (or credit card) product doesn't count payments that were made before the statement date towards the statement minimum amount, then `obligationAmount` must be always equal to the LOC level portion of the whole statement minimum amount.
Example:
- Migration period:
  - startDate: Aug 1, 2024
  - endDate: Aug 31, 2024
  - statementDate: Sep 1, 2024
  - dueDate: Sep 22, 2024
- Previous period (also called "past period"):
  - startDate: Jul 1, 2024
  - endDate: Jul 31, 2024
  - statementDate: Aug 1, 2024
  - dueDate: Aug 22, 2024

Scenario 1:
- A late fee of $15 was charged in the previous period on Jul 23, 2024 (on the LOC level). This fee is due on Aug 22, 2024.
- A borrower made some payments in the previous period, and based on your waterfall configuration in the legacy system, $5 out of $15 of the late fee was paid.
- The remaining fee amount of $10 is due on Aug 22, 2024.
- You should pass `obligationAmount=10`.

Scenario 2:
- A late fee of $15 was charged in the previous period on Jul 23, 2024 (on LOC level). This fee is due on Aug 22, 2024.
- A borrower made some payments in the previous period, and based on your waterfall configuration in the legacy system, none of the payments were counted toward the $15 late fee.
- The late fee amount of $15 is due on Aug 22, 2024.
- You should pass `obligationAmount=15`.

Scenario 3:
- A late fee of $15 was charged in the previous period on Jul 23, 2024 (on LOC level). This fee is due on Aug 22, 2024.
- A borrower made early payments in the previous period, and based on your waterfall configuration in the legacy system, the payments were counted toward the $15 late fee.
- The remaining fee amount of $0 is due on Aug 22, 2024 (in other words, the borrower doesn't need to pay anything on Aug 22, 2024.)
- You should pass `obligationAmount=0`.

  - `paidOffDate` (string)
    The date the line was paid off in another system (not in Peach). Required only when
`postMigrationLoanStatus=paidOff`. The value must be after the line activation date and before the
migration cutoff date. Not allowed when `postMigrationLoanStatus` is not `paidOff`.

  - `postMigrationLoanChargedOffReason` (string)
    The reason for the line charge off. Only required if `migrationStatus=chargedOff`.
- `term` means the loan was charged off per loan type configuration after X days overdue.
- `fraudulent` means the loan was charged off for a fraudulent reason.
- `bankruptcy` means the loan was charged off because of bankruptcy.
- `legal` means the loan was charged off because of some legal reason.
    Enum: "term", "fraudulent", "bankruptcy", "legal"

  - `postMigrationLoanStatus` (string)
    The status of the line after a successful migration.
If you pass `accelerated` or `chargedOff`, the system will first migrate the line as "active" and then
immediately accelerate or charge off the line and its draws. The `effectiveDate` of the acceleration
or charge off will be equal to the "migration cutoff date".
If you pass `paidOff`, the line is migrated as a static line that can never transition to any other status.
Do not pass `obligation`, `gracePeriod`, or `balances` when `postMigrationLoanStatus` is `paidOff`.
    Enum: "active", "accelerated", "chargedOff", "paidOff"

## Response 200 fields (application/json):

  - `message` (string)
    Description of the server action or error.

  - `status` (integer)
    HTTP status code.

  - `data` (object)

  - `data.balances` (object)
    The balances passed here should be as of the "migration cutoff date" after the most recent statement was generated in your legal system.
For example:
- Migration period:
  - startDate: Aug 1, 2024
  - endDate: Aug 31, 2024
  - statementDate: Sep 1, 2024
  - dueDate: Sep 22, 2024
- Previous period (also called "past period"):
  - startDate: Jul 1, 2024
  - endDate: Jul 31, 2024
  - statementDate: Aug 1, 2024
  - dueDate: Aug 22, 2024
- Notes:
  - The balances should be as of Aug 1, 2024 after the statement was generated on Aug 1, 2024.

Do not double-count fees: a fee you charge on the LOC or a regular (non-static) draw that it belongs to with a charge date on or after the "migration cutoff date" writes itself to the ledger. For any such fee, either include its amount in these balances OR charge it through the fees endpoint; never both, or the borrower will be billed twice.

  - `data.balances.creditLimitAmount` (number, required)
    The line credit limit amount as of the "migration cutoff date".

  - `data.balances.dueBalances` (object, required)
    Due balances represent balances that are currently due.
Only fees can be passed inside the balance objects on LOC level.
All other balances are expected to be passed in the `Create migration period draw data` endpoint.

  - `data.balances.dueBalances.dueLateFeesAmount` (number, required)
    The late fees portion of `dueFeesAmount`.

  - `data.balances.dueBalances.dueOriginationFeesAmount` (number, required)
    The origination fees portion of `dueFeesAmount`.

  - `data.balances.nonDueBalances` (object, required)
    Non-due balances represent balances that are not yet due.
Only fees can be passed inside the balance objects on LOC level.
All other balances are expected to be passed in the `Create migration period draw data` endpoint.

  - `data.balances.nonDueBalances.nonDueLateFeesAmount` (number, required)
    The late fees portion of `nonDueFeesAmount`.

  - `data.balances.nonDueBalances.nonDueOriginationFeesAmount` (number, required)
    The origination fees portion of `nonDueFeesAmount`.

  - `data.balances.overdueBalances` (object, required)
    Overdue balances represent balances that are overdue.
Only fees can be passed inside the balance objects on LOC level.
All other balances are expected to be passed in the `Create migration period draw data` endpoint.

  - `data.balances.overdueBalances.overdueLateFeesAmount` (number, required)
    The late fees portion of `overdueFeesAmount`.

  - `data.balances.overdueBalances.overdueOriginationFeesAmount` (number, required)
    The origination fees portion of `overdueFeesAmount`.

  - `data.balances.reimbursementAmount` (number, required)
    The total amount that a lender owes to the borrower as of the "migration cutoff date".

  - `data.gracePeriod` (object)
    If you are not migrating past periods and the migration period is the first period of the LOC:
Don't pass the `gracePeriod` object.
If you are migrating past periods:
This is the entire LOC grace period details including all its draws.
The grace period data passed here corresponds to the previous period and not to the migration period. By the time you call this endpoint, you should have already created one or more past periods. The additional data that you pass here is only required for the previous period and not for all past periods. That's why the grace period data is part of the "Create migration period LOC data" vs "Create past periods data" endpoint.
The migration period is a "live" period in which you execute migration.
- Because the Peach system needs to know if the LOC is eligible for the grace period benefit when the migration period starts, the system
will use the `isGracePeriodEligible` passed here. If you pass `isGracePeriodEligible=true`, the system will start migration without
accruing interest in the "migration period". If you pass `isGracePeriodEligible=false`, the system will start migration with accruing
interest in the "migration period".
- On the "due date + 1" within the "migration period", the system evaluates the grace eligibility based on `fullBalanceAmount`, `fullBalanceMinusOverdueAmount` and payments made.
- If you migrate the LOC before the upcoming "due date", the system will evaluate the grace period eligibility in "live" and might revoke the benefit.
- If you migrate the LOC after the "due date", the system will evaluate the grace period eligibility as part of the "replay/migration" process.
Because of existing limitations with "replay", grace period eligibility cannot be revoked as part of the replay process. However, the replay
process can reinstate the grace period benefit (in other words, waive accrued interest from the start of the "migration period").
- Peach is responsible for generating the statement corresponding to the migration period on `migrationPeriod.statementDate` in the future.
The grace period details of the migration period will be calculated by the Peach system on `migrationPeriod.statementDate` in the future.

For example:
- Migration period:
  - startDate: Aug 1, 2024
  - endDate: Aug 31, 2024
  - statementDate: Sep 1, 2024
  - dueDate: Sep 22, 2024
- Previous period (also called "past period"):
  - startDate: Jul 1, 2024
  - endDate: Jul 31, 2024
  - statementDate: Aug 1, 2024
  - dueDate: Aug 22, 2024
Notes:
  - The grace period details that you need to pass correspond to the previous period that started on Jul 1, 2024 and ended on Jul 31, 2024.
  - The amounts and values should be as of the "migration cutoff date", Aug 1, 2024, after the statement was finalized in your legacy system.

  - `data.gracePeriod.fullBalanceAmount` (number, required)
    The full balance amount of the line that is eligible for grace period.

  - `data.gracePeriod.fullBalanceMinusOverdueAmount` (number, required)
    The full balance amount minus the overdue amount.

  - `data.gracePeriod.isGracePeriodEligible` (boolean)
    Was the loan eligible for grace in this period?

  - `data.migrationPeriod` (object)
    The migration period.
The "migration cutoff date" will be set to the `startDate` passed here. It's important to understand that `migrationPeriod.statementDate` and `migrationPeriod.dueDate` are future dates. The previous period's `dueDate` is also a future date (relative to when you execute the migration) and falls in the "migration period".
For example:
- Migration period:
  - startDate: Aug 1, 2024
  - endDate: Aug 31, 2024
  - statementDate: Sep 1, 2024
  - dueDate: Sep 22, 2024
- Previous period (also called "past period"):
  - startDate: Jul 1, 2024
  - endDate: Jul 31, 2024
  - statementDate: Aug 1, 2024
  - dueDate: Aug 22, 2024
Notes:
  - "Migration cutoff date" is Aug 1, 2024.
  - If you execute the migration on Aug 10, 2024, the "migration at date" is Aug 10.
  - Previous period's `dueDate`, Aug 22, 2024, falls in the "migration period" that starts on Aug 1, 2024 and ends on Aug 31, 2024.
  - The upcoming due date is Aug 22, 2024.
  - If you didn't complete the migration before Aug 22, 2024, you need to cancel the loan and start the process again.

  - `data.migrationPeriod.dueDate` (string, required)

  - `data.migrationPeriod.endDate` (string, required)

  - `data.migrationPeriod.id` (string)

  - `data.migrationPeriod.object` (string)
    Enum: "loanPeriod"

  - `data.migrationPeriod.startDate` (string, required)

  - `data.migrationPeriod.statementDate` (string, required)

  - `data.obligation` (object)
    If you are not migrating past periods and the migration period is the first period of the LOC:
Don't pass the `obligation` object.
If you are migrating past periods:
This is the LOC level obligation details only (excluding any draws).
The data passed here corresponds to the previous period and not to the migration period. By the time you call this endpoint, you should've already created one or more past periods. The additional data that you pass here is only required for the previous period and not for all past periods. That's why the additional obligation data is part of the "Create migration period LOC data" vs "Create past periods data" endpoint.
To remind, the migration period is a "live" period in which you execute migration. The obligation details of the migration period will be calculated by the Peach system. Peach is also responsible for generating the statement corresponding to the migration period on `migrationPeriod.statementDate` in the future.
For example:
- Migration period:
  - startDate: Aug 1, 2024
  - endDate: Aug 31, 2024
  - statementDate: Sep 1, 2024
  - dueDate: Sep 22, 2024
- Previous period (also called "past period"):
  - startDate: Jul 1, 2024
  - endDate: Jul 31, 2024
  - statementDate: Aug 1, 2024
  - dueDate: Aug 22, 2024
- Notes:
  - The obligation details that you need to pass correspond to the previous period that started on Jul 1, 2024 and ended on Jul 31, 2024.
  - The amounts and other values should be as of the "migration cutoff date", Aug 1, 2024, after the statement was finalized in your legacy system.

  - `data.obligation.migratedDaysOverdue` (integer, required)
    This represents the number of days overdue prior to the "migration cutoff" date as it appears in
the other system (not Peach). This value is normally calculated as the number of calendar
days overdue starting from the earliest overdue obligation's due date to the
"migration cutoff date". This value, once set, won't change after the migration.
This value will be prorated and added to `daysOverdue` of future obligations
(if any become overdue). The system will prorate the `migratedDaysOverdue`
dynamically as the borrower makes payments and add it to the days overdue
post "migration cutoff date".
Calculation details:
- The `migratedDaysOverdue` value will be used to prorate days overdue prior to the "migration cutoff date"
based on the paid balance of `migratedOverdueAmount` (which is set based on the `balances.overdueBalances`).
- round_down [migratedDaysOverdue x (1 - min(fulfilledAmount / migratedOverdueAmount, 1))]
- For example:
  - migratedDaysOverdue = 60
  - migratedOverdueAmount = $1000
  - Scenario 1:
    - Borrower didn't make any payment within the first 30 days after the "migration cutoff date".
    - Total days overdue:
      - 60 x (1 - min(0 / 1000, 1)) + 30 = 90
  - Scenario 2:
    - Borrower made payments in a total amount of $700 within the first 30 days after the "migration cutoff date". The line is still overdue.
    - Total days overdue:
      - 60 x (1 - min(700 / 1000, 1)) + 30 = 48

  - `data.obligation.migratedOverdueFromDate` (string)
    The date from which the account is overdue at the time of migration. This attribute will also
be used to calculate "Date Of First Delinquency" for credit bureaus reporting.
If `migratedDaysOverdue > 0`, then `migratedOverdueFromDate` is required.

  - `data.obligation.obligationAmount` (number, required)
    The remaining amount of the previous period's obligation that a borrower needs to pay on the due date that comes after "migration cutoff date". The remaining amount should be as of "migration cutoff date" vs. "migration at date".
This is the LOC level remaining obligation amount excluding any draws' obligation amounts. Only fees can be passed inside the balance objects on LOC level. All other balances are expected to be passed in the `Create migration period draw data` endpoint.
If your LOC (or credit card) product doesn't count payments that were made before the statement date towards the statement minimum amount, then `obligationAmount` must be always equal to the LOC level portion of the whole statement minimum amount.
Example:
- Migration period:
  - startDate: Aug 1, 2024
  - endDate: Aug 31, 2024
  - statementDate: Sep 1, 2024
  - dueDate: Sep 22, 2024
- Previous period (also called "past period"):
  - startDate: Jul 1, 2024
  - endDate: Jul 31, 2024
  - statementDate: Aug 1, 2024
  - dueDate: Aug 22, 2024

Scenario 1:
- A late fee of $15 was charged in the previous period on Jul 23, 2024 (on the LOC level). This fee is due on Aug 22, 2024.
- A borrower made some payments in the previous period, and based on your waterfall configuration in the legacy system, $5 out of $15 of the late fee was paid.
- The remaining fee amount of $10 is due on Aug 22, 2024.
- You should pass `obligationAmount=10`.

Scenario 2:
- A late fee of $15 was charged in the previous period on Jul 23, 2024 (on LOC level). This fee is due on Aug 22, 2024.
- A borrower made some payments in the previous period, and based on your waterfall configuration in the legacy system, none of the payments were counted toward the $15 late fee.
- The late fee amount of $15 is due on Aug 22, 2024.
- You should pass `obligationAmount=15`.

Scenario 3:
- A late fee of $15 was charged in the previous period on Jul 23, 2024 (on LOC level). This fee is due on Aug 22, 2024.
- A borrower made early payments in the previous period, and based on your waterfall configuration in the legacy system, the payments were counted toward the $15 late fee.
- The remaining fee amount of $0 is due on Aug 22, 2024 (in other words, the borrower doesn't need to pay anything on Aug 22, 2024.)
- You should pass `obligationAmount=0`.

  - `data.paidOffDate` (string)
    The date the line was paid off in another system (not in Peach). Required only when
`postMigrationLoanStatus=paidOff`. The value must be after the line activation date and before the
migration cutoff date. Not allowed when `postMigrationLoanStatus` is not `paidOff`.

  - `data.postMigrationLoanChargedOffReason` (string)
    The reason for the line charge off. Only required if `migrationStatus=chargedOff`.
- `term` means the loan was charged off per loan type configuration after X days overdue.
- `fraudulent` means the loan was charged off for a fraudulent reason.
- `bankruptcy` means the loan was charged off because of bankruptcy.
- `legal` means the loan was charged off because of some legal reason.
    Enum: "term", "fraudulent", "bankruptcy", "legal"

  - `data.postMigrationLoanStatus` (string)
    The status of the line after a successful migration.
If you pass `accelerated` or `chargedOff`, the system will first migrate the line as "active" and then
immediately accelerate or charge off the line and its draws. The `effectiveDate` of the acceleration
or charge off will be equal to the "migration cutoff date".
If you pass `paidOff`, the line is migrated as a static line that can never transition to any other status.
Do not pass `obligation`, `gracePeriod`, or `balances` when `postMigrationLoanStatus` is `paidOff`.
    Enum: "active", "accelerated", "chargedOff", "paidOff"

  - `data.migratedOverdueAmount` (number)