How does the parking lot work?

Individual submissions are typically part of a trade. To avoid inconsistencies, certain submissions need to be held back to allow other submissions to get validated or previously rejected submissions to get fixed.

When do submissions get parked? 

As submissions enter the KOR Reporting Services, they follow these steps in order:

1. Submissions are identified, potentially evaluating configured HUB KDM rules for the KOR lifecycle identifier and the event timestamp.
2. If the KOR lifecycle identifier of the submission is not known to us, a trade state is created.
3. If we know the KOR lifecycle identifier, but the associated trade state passed the expiration date with over a week, we need to rehydrate the trade state from cold storage. This leads to the identified submission being parked for REHYDRATING TRADE STATE. This ends the flow of this submission until rehydration has been completed.
4. Once we create or find the trade state, the submission can be initialized, potentially evaluating configured HUB KDM rules for any field.
5. Initialized submissions get picked up by the eligibility service, which potentially uses Droit to evaluate the eligibility of the submission's mandates.
6. Submissions not deemed eligible to report for any mandate end the flow here.
7. Otherwise, regulatory messages are created for the eligible mandates, potentially evaluating configured regulation-specific (REG KDM) rules for any field.
8. The trade state is used to look up the "regulatory transaction" for the specific mandate the regulatory message is created for. It uses the following five fields:
   1. The jurisdiction.
   2. The message type.
   3. The KOR regulatory lifecycle identifier.
   4. The field from which the KOR regulatory lifecycle identifier was retrieved.
   5. The value of my entity identifier.
9. If the regulatory transaction has a previously unresolved rejected message, and its event timestamp is before the event timestamp of the submission's regulatory message, the submission for the regulatory message's mandate is parked for a PRIOR UNRESOLVED REJECTION. In other words, if the submission's event timestamp is after a prior rejected message for the same previously validated trade, we park the submission for the specific mandate. This ends the flow of this regulatory message until the prior rejection has been either ignored or resolved by sending in a new submission which hopefully resolves the rejected message using the same event timestamp.
10. Hence, if the event timestamp of the trade state's regulatory transaction and the submission's event timestamp were equal, it would not be parked as it likely intends to resolve the prior rejected message.
11. In case the trade state's regulatory transaction has never been in a validated state, no messages are parked to help speed up the process to get to a valid state as soon as possible.
12. If a prior regulatory message is going through the pre-validation phase, but we haven't received a determination yet, the newer regulatory message is parked for PRECEDING TRADE EVENT PENDING. These parked messages will resolve themselves promptly.
13. Regulatory messages are sent to pre-validation.
14. Once completed, the regulatory messages are registered as expected future states in the applicable trade state's regulatory transaction of the trade state. Expected, because we don't know for certain whether the TR will accept the regulatory message. The expected future state is determined by applying the valid regulatory message to the latest expected future state (or current state in case everything has been processed by the TR). The result is stored as the new latest expected future state of the trade state's regulatory transaction. Either the last valid event timestamp or the last rejected event timestamp gets updated in the trade state's regulatory transaction, based on the pre-validation result.
    Eventually, these expected future states get promoted to actual trade state once the TR validates the regulatory messages as well.

How are submissions released from the parking lot?

Releasing submissions is dependent on the reason why submissions were parked.

Rehydrating Trade State

When submissions are parked due to the trade state being rehydrated, it's only a matter of time before they get released automatically. There is no manual action that can be undertaken to force release.

The moment a trade's state is rehydrated, all submissions for that trade are released from the parking lot, as long as the reason for parking is the rehydration. They are released in the order of the submissions' event timestamps. This means it's possible submissions are reordered during the release.

Released submissions keep the same submission identifier as before they were parked.

Preceding Trade Event Pending

Submissions that are parked due to an ongoing preceding trade event, will be released automatically once the pending pre-validation of the preceding event has been completed. Just like with rehydrations, there is no manual action that can be undertaken to force release.

Aside from parked submissions for rehydration purposes, all parked submissions carry the specific mandate for the regulatory message they are created for. When releasing these parked submissions, they result in an identified submission with the same submission identifier as the pre-validated regulatory message, as well as the specific mandate of the parked submission.

The result of the pre-validation of the preceding event determines whether and how parked submissions are released.

• Valid pre-validation response for the preceding pending trade event:
  
  The trade state is updated to incorporate the preceding event. The preceding event gets applied to the latest known or expected future state in the applicable trade state's regulatory transaction, becoming the new latest expected future state.
  
  From all the available parked submissions with the same trade and mandate as the pre-validated regulatory message, the one with the oldest event timestamp gets released from the parking lot. This means it's possible submissions are reordered during the release.
  
  All other parked submissions for the same trade and specific mandate get their parked reason updated to PRECEDING TRADE EVENT PENDING, if that wasn't already the reason to begin with.
  
  
• Rejected pre-validation response for the preceding pending trade event:
  
  The trade state is updated to incorporate the preceding event. The trade state's regulatory transaction specific to the mandate of the regulatory message records the preceding event's event timestamp as the last rejected event timestamp.
  
  From all the available parked submissions with the same trade and mandate as the pre-validated regulatory message, only the one with the same event timestamp gets released from the parking lot, if it exists. This means it's possible submissions are reordered during the release.
  
  All other parked submissions for the same trade and specific mandate get their parked reason updated to PRIOR UNRESOLVED REJECTION, if that wasn't already the reason to begin with.

Released submissions follow the same flow as normal identified submissions. They get initialized, potentially reevaluating configured HUB KDM rules for any field, as they might want to pull from the updated trade state after the preceding pre-validated submission got applied to it.

Prior Unresolved Rejection

Submissions parked due to prior unresolved rejections do not get automatically resolved. Either a new submission needs to be sent in, or the prior unresolved rejection needs to be ignored to release parked submissions of this type.

They apply the same release logic as the PRECEDING TRADE EVENT PENDING parked submissions.