Rate Lock Requests

Best Practices

Sell Side Data in Rate Lock Requests

Use Case: Customers and partners (such as hedging and trading technology companies) desire to automate the population of Sell Side data within the rate lock request. The Sell Side data has native integration to "standard fields" that are represented on forms such as the purchase advice. The challenge is that the collection of lock requests represent a complex workflow, including loan snapshots, invoked in different ways based on the patterns used in the various lock request APIs available. Customers will have a desire to NOT disturb areas of the loan/lock records as other business processes have the propensity to be the system-of-record. Due to the static nature (by design) of snapshots of loan data captured native within each request - it is probably that it might be considered "old" when other business processes have performed updates. A very common case of this is that an underwriter might have the opportunity to make a minor change in the loan amount (say the consumer has a minor change in cash available for down payment) that doesn't flow through the lock request due to no material impact in pricing. We need to make sure updating the rate lock request does NOT overwrite the underwriters changes with the old snapshot of the loan amount.

Here is the recommended API orchestration for the use case described above:

  1. Interrogate the rate lock requests in the loan: It will be used subsequently to perform what is essentially a revision of the lock. The response in the collection will be sorted in descending order automatically.
  2. Determine which request is appropriate for injecting Sell Side information: This is especially important as we do NOT want to modify the incorrect rate lock. Within the collection could exist "requested and not confirmed" or a "cancelled" rate lock. Take the most recent rate lock request that has a lockStatus as "locked", "old lock", or "expired". It is appropriate that one might be editing an expired lock, as the placement of the loan may happen well beyond the commitment to the consumer.
  3. Create a new rate lock request derived on step #2. The assumption is that this new lock will be automatically confirmed. The important thing is that we are setting the option for noSync. This effectively eliminates the synchronization of the snapshot back to the loan; however, it will still synchronize the intended case of the sell-side detail.

Download a sample Postman collection here: Sell Side Rate Lock Postman Sample Collection