Date on which future_requirements becomes the main requirements hash and future_requirements becomes empty. After the transition, currently_due requirements may immediately become past_due, but the account may also be given a grace period depending on its enablement state prior to transitioning.
Fields that need to be resolved to keep the account enabled. If not resolved by future_requirements[current_deadline], these fields will transition to the main requirements hash.
This is typed as an enum for consistency with requirements.disabled_reason.
Details about validation and verification failures for due requirements that must be resolved.
Fields you must collect when all thresholds are reached. As they become required, they appear in currently_due as well.
Fields that haven't been resolved by requirements.current_deadline. These fields need to be resolved to enable the capability on the account. future_requirements.past_due is a subset of requirements.past_due.
Fields that are being reviewed, or might become required depending on the results of a review. If the review fails, these fields can move to eventually_due, currently_due, past_due or alternatives. Fields might appear in eventually_due, currently_due, past_due or alternatives and in pending_verification if one verification fails but another is still pending.
Fields that are due and can be resolved by providing the corresponding alternative fields instead. Many alternatives can list the same
original_fields_due, and any of these alternatives can serve as a pathway for attempting to resolve the fields again. Re-providingoriginal_fields_duealso serves as a pathway for attempting to resolve the fields again.