Struct ReportingDepositAccountApplicationsSchema

Source
pub struct ReportingDepositAccountApplicationsSchema {
Show 104 fields pub as_of_datetime: String, pub application_created_datetime: String, pub application_id: String, pub application_number: Option<String>, pub lead_source: Option<String>, pub app_source_marketing_tag: Option<String>, pub applicant_signup_url: Option<String>, pub is_single_app_flow_application: Option<bool>, pub prefill_source_application_id: Option<String>, pub prefill_source_application_type: Option<String>, pub primary_assigned_reviewer_user_id: Option<String>, pub primary_assigned_reviewer_full_name: Option<String>, pub primary_assigned_reviewer_email: Option<String>, pub primary_assigned_reviewer_branch_id: Option<String>, pub primary_assigned_reviewer_employee_id: Option<String>, pub primary_assigned_reviewer_nmls_id: Option<String>, pub product_bundle_reference_id: Option<String>, pub total_numberof_accounts_in_bundle: Option<i64>, pub debit_card_selected: Option<bool>, pub overdraft_protection_selected: Option<bool>, pub number_of_checking_accounts: Option<i64>, pub checking_product_reference_ids: Option<String>, pub checking_product_names: Option<String>, pub number_of_savings_accounts: Option<i64>, pub savings_product_reference_ids: Option<String>, pub savings_product_names: Option<String>, pub numberof_cd_accounts: Option<i64>, pub cd_product_reference_ids: Option<String>, pub cd_product_names: Option<String>, pub cd_terms: Option<String>, pub numberof_hsa_accounts: Option<i64>, pub hsa_product_reference_ids: Option<String>, pub hsa_product_names: Option<String>, pub hsa_plan_types: Option<String>, pub total_number_of_applicants: Option<i64>, pub number_of_primary_applicants: Option<i64>, pub primary_applicant_employment_status: Option<String>, pub primary_applicant_is_existing_member: Option<bool>, pub number_of_coapplicants: Option<i64>, pub coapplicant_employment_status: Option<String>, pub number_of_minor_applicants: Option<i64>, pub first_ui_tracking_event_datetime: Option<String>, pub first_minor_info_workflow_event_datetime: Option<String>, pub first_personal_info_workflow_event_datetime: Option<String>, pub has_activity_beyond_initial_details_task: Option<bool>, pub device_typestart: Option<String>, pub first_idv_workflow_event_datetime: Option<String>, pub first_idv_workflow_submit_datetime: Option<String>, pub first_idv_workflow_additional_info_requested_datetime: Option<String>, pub first_account_setup_workflow_event_datetime: Option<String>, pub has_beneficiaries_added: Option<bool>, pub application_submitted_datetime: Option<String>, pub application_submission_status: Option<String>, pub total_number_of_followups_requested: Option<i64>, pub first_automated_approval_datetime: Option<String>, pub first_automated_referral_datetime: Option<String>, pub first_automated_rejection_datetime: Option<String>, pub first_automated_rejection_source: Option<String>, pub primary_applicant_rejected_via_aan: Option<bool>, pub coapplicant_rejected_via_aan: Option<bool>, pub first_manual_approval_datetime: Option<String>, pub first_manual_approval_reviewer_user_id: Option<String>, pub first_manual_approval_reviewer_full_name: Option<String>, pub first_manual_approval_reviewer_email: Option<String>, pub first_manual_approval_reviewer_branch_id: Option<String>, pub first_manual_approval_reviewer_employee_id: Option<String>, pub first_manual_approval_reviewer_nmls_id: Option<String>, pub first_manual_rejection_datetime: Option<String>, pub first_manual_rejection_reviewer_user_id: Option<String>, pub first_manual_rejection_reviewer_full_name: Option<String>, pub first_manual_rejection_reviewer_email: Option<String>, pub first_manual_rejection_reviewer_branch_id: Option<String>, pub first_manual_rejection_reviewer_employee_id: Option<String>, pub first_manual_rejection_reviewer_nmls_id: Option<String>, pub latest_decision_datetime: Option<String>, pub latest_decision_type: Option<String>, pub latest_decision_outcome: Option<String>, pub latest_decision_automated_rejection_source: Option<String>, pub latest_decision_reviewer_user_id: Option<String>, pub latest_decision_reviewer_full_name: Option<String>, pub latest_decision_reviewer_email: Option<String>, pub latest_decision_reviewer_branch_id: Option<String>, pub latest_decision_reviewer_employee_id: Option<String>, pub latest_decision_reviewer_nmls_id: Option<String>, pub application_approval_status: Option<String>, pub account_booked_to_core_datetime: Option<String>, pub application_booking_status: Option<String>, pub first_funding_workflow_event_datetime: Option<String>, pub first_opening_deposit_transaction_submitted_datetime: Option<String>, pub number_of_new_accounts_funded: Option<i64>, pub opening_deposit_amounts: Option<String>, pub total_amount_deposited: Option<i64>, pub opening_deposit_source_account_connection_method: Option<String>, pub opening_deposit_source_account_type: Option<String>, pub application_funding_status: Option<String>, pub application_status_overall: Option<String>, pub first_online_banking_registration_workflow_event_datetime: Option<String>, pub online_banking_registration_completed_datetime: Option<String>, pub application_late_touch_datetime: Option<String>, pub application_last_touched_by_user_id: Option<String>, pub application_last_updated_datetime: Option<String>, pub application_archived_datetime: Option<String>, pub application_deleted_datetime: Option<String>, pub application_purged_datetime: Option<String>,
}

Fields§

§as_of_datetime: String

UTC datetime of when the data in the report was last refreshed.

§application_created_datetime: String

UTC datetime of when the application was created.

§application_id: String

The UUID of the application in Blend’s system. The static identifier that should be used to connect the application’s identity across Blend and external integrations.

§application_number: Option<String>

Application number displayed in the Blend Workspace.

§lead_source: Option<String>

Type of party that created the application, either “BORROWER” (i.e. the applicant) or “LENDER”.

§app_source_marketing_tag: Option<String>

Marketing identifier of the top-of-funnel campaign to which the application should be attributed.

§applicant_signup_url: Option<String>

URL of the page through which the primary applicant first created a Blend account. This URL may contain useful referral information if the applicant first arrived at the signup page through a lender-user’s custom link or invitation. If there is no URL associated with the primary applicant, this field falls back on the first signup URL associated with the application overall (i.e. that of a coapplicant), if any.

§is_single_app_flow_application: Option<bool>

Boolean indicator for whether the deposit account application was created (and prefilled) via the “Single App Flow” feature, wherein the applicant had actually started by submitting an application for another product, such as a credit card or a loan, for which the applicant must hold a deposit account in order to be eligible. In this situation, the applicant would have been taken from that original application into a new deposit account application with as many fields prefilled as possible based on the applicant’s responses in preceding application.

§prefill_source_application_id: Option<String>

In the case of a “Single App Flow” application, the application_id of the applicant’s previous credit card or loan application from which the new required deposit account application was prefilled.

§prefill_source_application_type: Option<String>

IIn the case of a “Single App Flow” application, the product for which the applicant was originally applying, i.e. the product associated with the prefill_source_application_id; for example “Credit Card”, “Personal Loan”, “Auto Loan”, etc.

§primary_assigned_reviewer_user_id: Option<String>

Blend user ID of the application’s primary assigned lender-user.

§primary_assigned_reviewer_full_name: Option<String>

Full name in the primary assigned reviewer’s user profile.

§primary_assigned_reviewer_email: Option<String>

Email address of the primary assigned reviewer.

§primary_assigned_reviewer_branch_id: Option<String>

Branch ID in the primary assigned reviewer’s user profile.

§primary_assigned_reviewer_employee_id: Option<String>

Employee ID in the primary assigned reviewer’s user profile.

§primary_assigned_reviewer_nmls_id: Option<String>

Nationwide Multistate Licensing System ID in the primary assigned reviewer’s user profile.

§product_bundle_reference_id: Option<String>

Product bundle ID associated with the application (a single application can open multiple accounts, e.g. “Checking & Savings”).

§total_numberof_accounts_in_bundle: Option<i64>

Number of accounts in the product bundle that will be opened if the application is approved.

§debit_card_selected: Option<bool>

Booelan indicator for whether the applicant opted in for a debit card.

§overdraft_protection_selected: Option<bool>

Boolean indicator for whether the applicant opted in for overdraft protection.

§number_of_checking_accounts: Option<i64>

Number of checking accounts in the product bundle that will be opened if the application is approved.

§checking_product_reference_ids: Option<String>

Product ID(s) of the specific checking product(s) in the bundle; may be the same as the productBundleReferenceId if the application is for a single checking account. This field will contain a comma-separated list of IDs when the application is for a multi-account bundle containing more than one checking account.

§checking_product_names: Option<String>

Full humanized name(s) of the checking product(s) in the bundle. This field will contain a comma-separated list of names when the application is for a multi-account bundle with more than one checking account.

§number_of_savings_accounts: Option<i64>

Number of savings accounts in the product bundle that will be opened if the application is approved.

§savings_product_reference_ids: Option<String>

Product ID(s) of the specific savings product(s) in the bundle; may be the same as the productBundleReferenceId if the application is for a single savings account. This field will contain a comma-separated list of identifiers when the application is for a multi-account bundle containing more than one savings account.

§savings_product_names: Option<String>

Full humanized name(s) of the savings product(s) in the bundle. This field will contain a comma-separated list of names when the application is for a multi-account bundle with more than one savings account.

§numberof_cd_accounts: Option<i64>

Number of certificates of deposit (CDs) in the product bundle that will be opened if the application is approved.

§cd_product_reference_ids: Option<String>

Product ID(s) of the specific CD product(s) in the bundle; may be the same as the productBundleReferenceId if the application is for a single CD. This field will contain a comma-separated list of identifiers when the application is for a multi-account bundle containing more than one CD.

§cd_product_names: Option<String>

Full humanized name(s) of the CD product(s) in the bundle. This field will contain a comma-separated list of names when the application is for a multi-account bundle with more than one CD.

§cd_terms: Option<String>

Chosen term length(s) of the CD(s) in the bundle, appearing as strings such as “12_MONTHS” and “36_MONTHS”. This field will contain a comma-separated list of term lengths when the application is for a multi-account bundle with more than one CD.

§numberof_hsa_accounts: Option<i64>

Number of health savings accounts (HSAs) in the product bundle that will be opened if the application is approved.

§hsa_product_reference_ids: Option<String>

Product ID(s) of the specific HSA product(s) in the bundle; may be the same as the productBundleReferenceId if the application is for a single HSA. This field will contain a comma-separated list of identifiers when the application is for a multi-account bundle containing more than one HSA.

§hsa_product_names: Option<String>

Full humanized name(s) of the HSA product(s) in the bundle. This field will contain a comma-separated list of names when the application is for a multi-account bundle with more than one HSA.

§hsa_plan_types: Option<String>

Chosen plan type(s) of the HSA(s) in the bundle, either “INDIVIDUAL” or “FAMILY”. This field will contain a comma-separated list of plan types when the application is for a multi-account bundle with more than one HSA.

§total_number_of_applicants: Option<i64>

Number of applicants on the application (primary, co-, and minor applicants).

§number_of_primary_applicants: Option<i64>

Number of primary applicants on the application. Every application should have one primary applicant.

§primary_applicant_employment_status: Option<String>

Employment status of the primary applicant. There are five statuses the applicant can choose from, including “EMPLOYED”, “SELF_EMPLOYED”, “UNEMPLOYED”, “RETIRED”, and “NEVER_EMPLOYED”.

§primary_applicant_is_existing_member: Option<bool>

Boolean indicator that is TRUE if the primary applicant indicated that they are an existing member of the institution.

§number_of_coapplicants: Option<i64>

Number of coapplicants on the application.

§coapplicant_employment_status: Option<String>

Employment status of the coapplicant. There are five statuses the coapplicant can choose from, including “EMPLOYED”, “SELF_EMPLOYED”, “UNEMPLOYED”, “RETIRED”, and “NEVER_EMPLOYED”.

§number_of_minor_applicants: Option<i64>

Number of minor applicants (i.e. persons under 18) on the application.

§first_ui_tracking_event_datetime: Option<String>

UTC datetime of the first tracking event associated with the application. The presence of an event should indicate that the applicant at least allowed the UI to load.

§first_minor_info_workflow_event_datetime: Option<String>

UTC datetime of the first tracking event in the “Minor Info” workflow.

§first_personal_info_workflow_event_datetime: Option<String>

UTC datetime of the first tracking event in the “Personal Info” workflow.

§has_activity_beyond_initial_details_task: Option<bool>

Boolean indicator compiling all possible downfunnel evidence that the application made it past the initial “Get Applicant Details” task in the “Personal Info” workflow. The field is intended to be used as a more qualified definition of “started”, with a value of TRUE identifying applications that were not abandoned on the first page.

§device_typestart: Option<String>

Type of device (“Desktop”, “Mobile”, or “Tablet”) used for the application’s first user action, which should correspond to clicking “continue” on the first page of the application.

§first_idv_workflow_event_datetime: Option<String>

UTC datetime of the first tracking event in the “Identity Verfication” workflow.

§first_idv_workflow_submit_datetime: Option<String>

UTC datetime of the first click on “Submit and Continue” on the final page of the “Identity Verification” workflow, which should submit the applicant’s information to the third-party identity verification (IDV) provider (Alloy or Socure). The exception to this is when the applicant is an existing member of the institution, and the institution has configured its application to “offboard” existing members from the application without submission to the IDV provider.

§first_idv_workflow_additional_info_requested_datetime: Option<String>

UTC datetime of the first time an applicant was sent to the supplementary “Step Up” task in the “Identity Verification” workflow, where additional identifying information is requested, if the initial ID information provided was found to be insufficient for evaluation/decisioning.

§first_account_setup_workflow_event_datetime: Option<String>

UTC datetime of the first tracking event in the “Account Setup” workflow.

§has_beneficiaries_added: Option<bool>

Boolean indicator for whether any beneficiaries were specified and allocated for the new account(s) in the “Account Setup” workflow.

§application_submitted_datetime: Option<String>

UTC datetime of application submission.

§application_submission_status: Option<String>

Supplementary status indicator that may be able to confirm application submission even in the case of a lapse in the event tracking that produces applicationSubmittedDatetime; either “SUBMITTED” or “NOT SUBMITTED”.

§total_number_of_followups_requested: Option<i64>

Number of follow-up tasks requested of the applicant by a lender-user through Blend’s “Follow-Ups” tool.

§first_automated_approval_datetime: Option<String>

UTC datetime of the first automated approval decision on the application emitted by the third-party identity verification (IDV) provider (Alloy or Socure). An approval decision will not be emitted unless and until the application is submitted.

§first_automated_referral_datetime: Option<String>

UTC datetime of the first automated referral on the application, where the third-party identity verification (IDV) provider (Alloy or Socure) flags the application for manual review by a lender-user. A referral decision will not be made unless and until the application is submitted.

§first_automated_rejection_datetime: Option<String>

UTC datetime of the first automated rejection decision by the third-party identity verification (IDV) provider (Alloy or Socure) or by the “system” (i.e. application configurations set by the institution to reject/“offboard” certain applicants, like existing members, on the spot). A rejection decision can be emitted prior to application submission if the applicant fails the basic preliminary IDV screening (because of a low Qualifile score) and triggers an “adverse action notice” (AAN) in the “Identity Verification” workflow, or if they are rejected by system rules.

§first_automated_rejection_source: Option<String>

Source of the first automated rejection decision, either “IDV provider” (Alloy or Socure) or “system” (i.e. application configurations set by the institution to reject/“offboard” certain applicants, like existing members, on the spot).

§primary_applicant_rejected_via_aan: Option<bool>

Booelan indicator for whether the primary applicant was rejected via “adverse action notice” (AAN) based on their “Qualifile” score in the “Identity Verification” workflow, which would result in an immediate rejection of the application without proceeding to the “Account Setup” workflow. If the applicant has not yet submitted their information for IDV evaulation, this field will be null.

§coapplicant_rejected_via_aan: Option<bool>

Booelan indicator for whether the coapplicant was rejected via “adverse action notice” (AAN) based on their “Qualifile” score in the “Identity Verification” workflow. If there is no coapplicant on the application, or the coapplicant has not yet submitted their information for IDV evaulation, this field will be null.

§first_manual_approval_datetime: Option<String>

UTC datetime of the first manual approval decision on the application issued by a lender-user. An application cannot be reviewed or approved unless and until the application is submitted.

§first_manual_approval_reviewer_user_id: Option<String>

Blend user ID of the lender-user who manually approved the application.

§first_manual_approval_reviewer_full_name: Option<String>

Full name in the user profile of the lender-user who manually approved the application.

§first_manual_approval_reviewer_email: Option<String>

Email address of the lender-user who manually approved the application.

§first_manual_approval_reviewer_branch_id: Option<String>

Branch ID in the user profile of the lender-user who manually approved the application.

§first_manual_approval_reviewer_employee_id: Option<String>

Employee ID in the user profile of the lender-user who manually approved the application.

§first_manual_approval_reviewer_nmls_id: Option<String>

Nationwide Multistate Licensing System ID in the user profile of the lender-user who manually approved the application.

§first_manual_rejection_datetime: Option<String>

UTC datetime of the first manual rejection decision on the application issued by a lender user. An application cannot be reviewed or rejected unless and until the application is submitted.

§first_manual_rejection_reviewer_user_id: Option<String>

Blend user ID of the lender-user who manually rejected the application.

§first_manual_rejection_reviewer_full_name: Option<String>

Full name in the user profile of the lender-user who manually rejected the application.

§first_manual_rejection_reviewer_email: Option<String>

Email address of the lender-user who manually rejected the application.

§first_manual_rejection_reviewer_branch_id: Option<String>

Branch ID in the user profile of the lender-user who manually rejected the application.

§first_manual_rejection_reviewer_employee_id: Option<String>

Employee ID in the user profile of the lender-user who manually rejected the application.

§first_manual_rejection_reviewer_nmls_id: Option<String>

Nationwide Multistate Licensing System ID in the user profile of the lender-user who manually rejected the application.

§latest_decision_datetime: Option<String>

UTC datetime of the latest decision on the application, automated or manual, approval or rejection. See descriptions of first_automated_approval_datetime, first_automated_rejection_datetime, first_manual_approval_datetime, and first_manual_rejection_datetime for detail on each decision type and outcome. Referrals are not considered true “decisions” and thus are ignored by this field.

§latest_decision_type: Option<String>

Type, either “automated” or “manual”, of the latest decision on the appliction, approval or rejection. Referrals are not considered true “decisions” and thus are ignored by this field.

§latest_decision_outcome: Option<String>

Outcome, either “approve” or “reject”, of the latest decision on the application, automated or manual. Referrals are not considered true “decisions” and thus are ignored by this field.

§latest_decision_automated_rejection_source: Option<String>

If the latest decision on the application is an automated rejection, the source of that rejection, either “IDV provider” (Alloy or Socure) or “system” (i.e. application configurations set by the institution to reject/“offboard” certain applicants, like existing members, on the spot).

§latest_decision_reviewer_user_id: Option<String>

If the latest decision on the application is manual, the Blend user ID of the lender-user who made that decision.

§latest_decision_reviewer_full_name: Option<String>

If the latest decision on the application is manual, the full name in the user profile of the lender-user who made that decision.

§latest_decision_reviewer_email: Option<String>

If the latest decision on the application is manual, the email address of the lender-user who made that decision.

§latest_decision_reviewer_branch_id: Option<String>

If the latest decision on the application is manual, the branch ID in the user profile of the lender-user who made that decision.

§latest_decision_reviewer_employee_id: Option<String>

If the latest decision on the application is manual, the employee ID in the user profile of the lender-user who made the decision.

§latest_decision_reviewer_nmls_id: Option<String>

If the latest decision on the application is manual, the Nationwide Multistate Licensing System ID in the user profile of the lender-user who made that latest decision.

§application_approval_status: Option<String>

Approval status of the application, either “APPROVED”, “REFERRED”, or “REJECTED” if the application has reached a decisioning point, or null if not.

§account_booked_to_core_datetime: Option<String>

UTC datetime that the newly opened account(s) was successfully booked to the institution’s core banking system.

§application_booking_status: Option<String>

Supplementary status indicator that may be able to confirm that the newly opened account(s) was successfully booked even in the case of a lapse in the event tracking that produces accountBookedToCoreDatetime; either “BOOKED” or null.

§first_funding_workflow_event_datetime: Option<String>

UTC datetime of the first tracking event in the “Opening Deposit” workflow.

§first_opening_deposit_transaction_submitted_datetime: Option<String>

UTC datetime of the first deposit transaction submitted through the “Opening Deposit” workflow. The exception to this is for institutions that have configured their application to preemptively require the applicant to complete the opening deposit tasks in the “Account Setup” workflow prior to application submission, in which case this field will still report a datetime once those tasks have been completed, even if the application was never subsequently submitted, approved, and booked to the core banking system, and accordingly no opening deposits were actually transferred.

§number_of_new_accounts_funded: Option<i64>

Number of newly opened accounts funded with an initial deposit submitted through the “Opening Deposit” workflow. The exception to this is for institutions that have configured their application to preemptively require the applicant to complete the opening deposit tasks in the “Account Setup” workflow prior to application submission, in which case this field will still report the number of intended desintation accounts once those tasks have been completed, even if the application was never subsequently submitted, approved, and booked to the core banking system, and accordingly no opening deposits were actually transferred.

§opening_deposit_amounts: Option<String>

Dollar amount(s) of the opening deposit(s) submitted through the “Opening Deposit” workflow, rounded to the nearest increment of 50. This field will contain a comma-separated list of amounts when multiple newly opened accounts that originated from the same application were funded. The exception to this is for institutions that have configured their application to preemptively require the applicant to complete the opening deposit tasks in the “Account Setup” workflow prior to application submission, in which case this field will still report the intended deposit amount(s) once those tasks have been completed, even if the application was never subsequently submitted, approved, and booked to the core banking system, and accordingly no opening deposits were actually transferred.

§total_amount_deposited: Option<i64>

Sum of the dollar amounts (each rounded to the nearest increment of 50 prior to summation) of the opening deposits submitted through the “Opening Deposit” workflow; the sum will be the same as the value in opening_deposit_amounts if only one new account was funded. The exception to this is for institutions that have configured their application to preemptively require the applicant to complete the opening deposit tasks in the “Account Setup” workflow prior to application submission, in which case this field will still report the intended total deposit amount once those tasks have been completed, even if the application was never subsequently submitted, approved, and booked to the core banking system, and accordingly no opening deposits were actually transferred.

§opening_deposit_source_account_connection_method: Option<String>

Method used to connect an external source account for the transfer of an opening deposit in the “Opening Deposit” workflow. The applicant can either use the Plaid integration to log in to a financial institution, or manually enter the account and routing numbers of the source account. This field will have a value of either “Plaid”, “manual entry”, or “unknown” when first_opening_deposit_transaction_submitted_datetime is populated, and null otherwise. The exception to this is for institutions that have configured their application to preemptively require the applicant to complete the opening deposit tasks in the “Account Setup” workflow prior to application submission, in which case this field will still report the chosen connection method once those tasks have been completed, even if the application was never subsequently submitted, approved, and booked to the core banking system, and accordingly no opening deposits were actually transferred.

§opening_deposit_source_account_type: Option<String>

Type of source account used to fund the opening deposit, either “checking”, “savings”, or “unknown”. The account type (checking or savings) is known for all Plaid-connected source accounts, whereas this information is only collected for manually entered source accounts if the instutition has configured the application to ask the applicant to specify the account type. The exception to this is for institutions that have configured their application to preemptively require the applicant to complete the opening deposit tasks in the “Account Setup” workflow prior to application submission, in which case this field will still report the intended source account type once those tasks have been completed, even if the application was never subsequently submitted, approved, and booked to the core banking system, and accordingly no opening deposits were actually transferred.

§application_funding_status: Option<String>

Funding status of the application. This field will be “FUNDED VIA BLEND” if an opening deposit for at least one newly opened account was submitted through the “Opening Deposit” workflow (i.e. if application_booking_status = “BOOKED” and first_opening_deposit_transaction_submitted_datetime exists), and null otherwise.

§application_status_overall: Option<String>

Overall latest status of the application (i.e. the most down-funnel status reached to date), either “NOT SUBMITTED”, “SUBMITTED”, “REFERRED”, “APPROVED”, “REJECTED”, “BOOKED”, or “FUNDED VIA BLEND”.

§first_online_banking_registration_workflow_event_datetime: Option<String>

UTC datetime of the first tracking event in the “Online Banking Registration” workflow.

§online_banking_registration_completed_datetime: Option<String>

UTC datetime of when the new account holder succesfully created and submitted login credentials for online banking access at the institution via the “Online Banking Registration” workflow.

§application_late_touch_datetime: Option<String>

UTC datetime of when the application was last touched (by either an applicant or a lender-user).

§application_last_touched_by_user_id: Option<String>

Blend user ID of the applicant or lender-user who last touched the application.

§application_last_updated_datetime: Option<String>

UTC datetime of when the application record was last updated by the system.

§application_archived_datetime: Option<String>

UTC datetime of when the application was archived in Blend.

§application_deleted_datetime: Option<String>

UTC datetime of when the application was deleted by a user.

§application_purged_datetime: Option<String>

UTC datetime of when the application was purged from Blend production.

Trait Implementations§

Source§

impl Debug for ReportingDepositAccountApplicationsSchema

Source§

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter. Read more
Source§

impl<'de> Deserialize<'de> for ReportingDepositAccountApplicationsSchema

Source§

fn deserialize<__D>(__deserializer: __D) -> Result<Self, __D::Error>
where __D: Deserializer<'de>,

Deserialize this value from the given Serde deserializer. Read more
Source§

impl Display for ReportingDepositAccountApplicationsSchema

Source§

fn fmt(&self, f: &mut Formatter<'_>) -> Result<(), Error>

Formats the value using the given formatter. Read more
Source§

impl Serialize for ReportingDepositAccountApplicationsSchema

Source§

fn serialize<__S>(&self, __serializer: __S) -> Result<__S::Ok, __S::Error>
where __S: Serializer,

Serialize this value into the given Serde serializer. Read more

Auto Trait Implementations§

Blanket Implementations§

Source§

impl<T> Any for T
where T: 'static + ?Sized,

Source§

fn type_id(&self) -> TypeId

Gets the TypeId of self. Read more
Source§

impl<T> Borrow<T> for T
where T: ?Sized,

Source§

fn borrow(&self) -> &T

Immutably borrows from an owned value. Read more
Source§

impl<T> BorrowMut<T> for T
where T: ?Sized,

Source§

fn borrow_mut(&mut self) -> &mut T

Mutably borrows from an owned value. Read more
Source§

impl<T> From<T> for T

Source§

fn from(t: T) -> T

Returns the argument unchanged.

Source§

impl<T> Instrument for T

Source§

fn instrument(self, span: Span) -> Instrumented<Self>

Instruments this type with the provided Span, returning an Instrumented wrapper. Read more
Source§

fn in_current_span(self) -> Instrumented<Self>

Instruments this type with the current Span, returning an Instrumented wrapper. Read more
Source§

impl<T, U> Into<U> for T
where U: From<T>,

Source§

fn into(self) -> U

Calls U::from(self).

That is, this conversion is whatever the implementation of From<T> for U chooses to do.

Source§

impl<T> ToString for T
where T: Display + ?Sized,

Source§

fn to_string(&self) -> String

Converts the given value to a String. Read more
Source§

impl<T, U> TryFrom<U> for T
where U: Into<T>,

Source§

type Error = Infallible

The type returned in the event of a conversion error.
Source§

fn try_from(value: U) -> Result<T, <T as TryFrom<U>>::Error>

Performs the conversion.
Source§

impl<T, U> TryInto<U> for T
where U: TryFrom<T>,

Source§

type Error = <U as TryFrom<T>>::Error

The type returned in the event of a conversion error.
Source§

fn try_into(self) -> Result<U, <U as TryFrom<T>>::Error>

Performs the conversion.
Source§

impl<T> WithSubscriber for T

Source§

fn with_subscriber<S>(self, subscriber: S) -> WithDispatch<Self>
where S: Into<Dispatch>,

Attaches the provided Subscriber to this type, returning a WithDispatch wrapper. Read more
Source§

fn with_current_subscriber(self) -> WithDispatch<Self>

Attaches the current default Subscriber to this type, returning a WithDispatch wrapper. Read more
Source§

impl<T> DeserializeOwned for T
where T: for<'de> Deserialize<'de>,