Plaid Protect: Search Attributes and Create Custom Rule Groups

Last updated: October 13, 2026

Use Plaid Protect to investigate verification activity and create custom checks for your identity-verification workflow. This guide covers searching by attribute and configuring Rule Groups to reject a matching Plaid session or request additional verification.

Part 1 — Search by attribute in Plaid Protect

1. Open the attribute picker

Go to Protect → Overview and click Search by attribute…. Type a field name or browse the categories. Select the actual field from the results; typing its name alone does not add a filter.

For example, type user.pi.email and select the plain email field, rather than one of the email-risk fields underneath it.

Search the field name, then select the matching attribute.

2. Choose an operator and enter a value

Select Equal to (==), enter glide-kb-block@example.com, and press Enter to add the condition. The completed condition should read:

IF user.pi.email == glide-kb-block@example.com

The email field offers In, Not in, Equal to, Not equal to, Exists, and Does not exist. Other fields offer operators appropriate to their data type. Use the picker’s supported operator and value format.

Additional conditions in the same expression are joined with AND: all must match. To match any of several values for a single field, use In where available. Do not add “email equals A” AND “email equals B”; one email cannot equal both.

3. Run the search and review the results

Click the magnifying-glass search control or press Shift + Enter. Plaid opens Explore with your filter applied.

The synthetic email search returns zero events in this example.

Set the date range you want to investigate.
Select IDV for identity-verification events or Link for bank-linking events.
Use Customize columns, where enabled, to show the fields relevant to your investigation.
Open a matching event/session to examine its details and timeline. Confirm which fields actually have values before using them in a rule.

If there are no results, check the team, environment, date range, event type, spelling/value format, and whether Plaid collected that attribute. Results count events, not necessarily unique applicants or Glide applications.

Useful investigation patterns

Question	Useful fields	How to interpret it
Has a known identifier appeared again?	`user.pi.email`, `user.pi.phone`, `session.device_id`, `session.ip`	Find related activity and check the full session. Shared devices, IPs, and recycled phone numbers can connect different people.
Which sessions need closer risk review?	`event.trust_index_score`, `event.trust_level`, `session.ip.is_vpn`, `user.pi.email.is_disposable`	Combine risk signals with session evidence. Lower Trust Index means higher risk; a single signal is not an application decision.
Where did verification stop?	`session.idv.status`, `session.idv.datasource.step_status`, `session.idv.id_doc.step_status`, `session.idv.liveness.step_status`	Compare the overall session with individual step results.

Part 2 — Create Rule Groups and choose rejection or escalation

1. Create and name the group

Go to Protect → Rule Groups → New rule group. Click the pencil next to the group name and give it a clear purpose. For a staging exercise, use a name such as TEST – Block example email.

2. Add and save the rule

Click Add new rule.
Select user.pi.email, choose Equal to, and enter glide-kb-block@example.com.
Press Enter to create the condition chip.
Click the Save rule icon at the upper-right of the attribute composer.
Click Create rule group in the group panel. When editing an existing group, use its save/apply control.

“Workflows enabled on: None” means the group is not attached to a workflow. Saving a group does not, by itself, reject any sessions.

Add multiple conditions and rules

Conditions within one rule use AND; separate rules within a group use OR. Keep conditions in the same rule when they must all be true. Use Add new rule when you want another way for the group to match.

Example A: age AND email

Open the rule group and click Add new rule.
Select user.pi.age → Equal to (==) → enter 35 → press Enter.
In the same attribute composer, click Search by attribute… again. Select user.pi.email → Equal to (==) → enter glide-kb-block@example.com → press Enter.
Confirm the two condition chips are joined by AND, then click the Save rule icon.

This rule matches only when age is 35 AND the email equals the synthetic example email. Age 35 alone does not match. These values demonstrate the controls; replace them with your intended conditions.

Example B: city AND state as an alternative rule

Back in the group panel, click Add new rule again.
Select user.pi.address.city → Equal to → enter Springfield → press Enter.
In the same composer, add user.pi.address.region → Equal to → enter IL → press Enter. Plaid calls the state field region; use the state/region format present in your session data.
Save the rule. Confirm the group shows OR between the age/email rule and the city/state rule.
Click Create rule group, or the save/apply control when editing an existing group.

Two rules in one group: either complete pair can match.

(age == 35 AND email == glide-kb-block@example.com)
OR
(city == Springfield AND region == IL)

The group matches if the age/email pair is true, or the city/state pair is true. If you need all four conditions to be true, put all four in a single rule instead. For several acceptable values of one field, use In where available.

3. Choose rejection or escalation

Desired result	Where to configure it
Reject a matching Plaid session	Risk engine → Rule group execution → Reject user → Active
Request additional verification	Edit outcomes beneath Data source verification or Document verification → Use risk-based escalation → Rule groups

Option A: reject the matching session

Open Protect → Configure and select the template used by the Glide flow you want to change.
Check the environment and the Global / country context. Confirm the rule applies in the country configuration used by that flow.
Open Risk engine → Rule group execution.
Click Add rule group and select your group.
For an enforced failure, confirm the outcome is Reject user and the mode is Active.
Close the panel and click Publish Changes to make the template change effective. An Unpublished changes banner means the draft is not yet live.

The enforcement configuration is Rule group execution → your group → Reject user → Active. The pictured setup was inspected as an unpublished Sandbox draft.

Setting	Required for this example
Rule condition	`user.pi.email == glide-kb-block@example.com`
Workflow location	Risk engine → Rule group execution
Group outcome	Reject user
Execution mode	Active
Scope and save state	Correct team, environment, template, and applicable country configuration; changes published

When the condition matches in this configuration, the group is intended to reject the Plaid verification through the risk check. A nonmatching email only avoids this rule; the session can still fail another check.

Choose the right execution mode

Mode	Dashboard behavior
Active	Evaluates the group and affects the risk-check outcome.
Test	Evaluates the group without affecting the risk-check outcome. Use it to assess a rule before enforcement.
Inactive	Does not evaluate the group during the risk check.

Option B: escalate to another verification step

Use escalation when a match should request more verification. Configure it on the workflow’s passing-step path; the If this step fails, go to route is a separate setting.

In Protect → Configure, select the correct template and Global/country context. Use Manage modules to enable Document verification for escalation after Data source verification, and Liveness verification for escalation after Document verification. The corresponding Edit outcomes controls appear beneath those steps in the workflow.

After Data source verification:

Click Edit outcomes directly beneath the Data source verification block.
Under If this step passes, go to, turn on Use risk-based escalation.
Select Rule groups. If switching from Trust Index, Plaid asks you to confirm clearing the threshold.
Click Add rule group, open Select rule group…, and choose the saved group. Add other groups if needed; the first matching group triggers the escalation path.
Check then shows Document verification. Choose the else destination for a nonmatch. In this example, Risk engine continues the workflow without requesting document or liveness verification.
Review If this step fails, go to separately. The example sends a failed data-source check to Document verification.

Passing data-source check + matching group → Document verification. Passing check + no group match → Risk engine. The failed-step route is configured separately at the top.

After Document verification:

Click outside the first editor, then click Edit outcomes beneath the Document verification block.
Turn on Use risk-based escalation and use Rule groups → Add rule group to select the group for this stage. The document-stage list is separate from the data-source list.
Confirm then → Liveness verification and review the else and failed-step routes. In the pictured configuration, both of those routes continue to Risk engine; they do not change a failed document result into a pass.

Passing document check + matching group → Liveness verification. No match continues to Risk engine.

Selecting Trust Index instead of Rule Groups:

In the same Edit outcomes editor, keep Use risk-based escalation on and select Trust Index.
Click the threshold chip, such as Trust Index ≤ 75, and adjust the slider. A score at or below the selected threshold takes the then path; other scores take else. The displayed 75 is an example, not a recommended cutoff.
Review the destinations and the escalation setup after both verification steps before saving.

The threshold chip opens the slider. The workflow also shows the then and else routes.

Choose one escalation mechanism for the workflow. Trust Index and Rule Groups are alternatives, not simultaneous conditions. Changing the mechanism affects the workflow’s escalation mode; the group lists after Data source verification and Document verification are configured separately. Switching to Rule Groups clears the Trust Index setting; switching back removes the configured escalation groups. Review both stages, fill any empty required group lists, and resolve validation errors before publishing. Removing a group from an escalation list does not delete the saved Rule Group itself.

Click outside the editor, review the complete workflow, and click Publish Changes when the configuration is ready. Test matching and nonmatching cases in staging for each enabled escalation stage.

Using escalation and rejection together: You can configure an escalation path and a separate Risk engine → Rule group execution rejection rule in the same workflow. Keep their purposes clear: completing the extra verification does not disable an Active + Reject user rule that also matches later. If you only want additional verification, attach the group in the escalation editor rather than also making it an active rejection rule. Active / Test / Inactive are Risk engine execution modes; do not assume Test mode there disables an independently configured escalation path.

4. Validate in staging before enforcing

Search historical events with the intended conditions to review what would match.
Use Test mode to observe evaluation without changing risk-check outcomes.
In the approved staging/Sandbox flow, run one new session with the synthetic matching email and one with a different email. Confirm the correct template was used.
For an enforcement test, use Active + Reject user, publish the Sandbox change, and inspect the overall session and rule outcome in Plaid. Check that the different-email session does not match this rule; other checks may still fail.
Open the corresponding Glide application and check its status and verification rows separately. Remove or deactivate the temporary test configuration when finished.

Use Plaid’s supported Sandbox identities or Sample Identities. Sandbox does not reproduce every live check—for example, selfie verification does not run there—and repeated testing can affect network/device risk signals. See Plaid’s testing guide.

What will appear in Glide after Plaid fails?

Standard checks: Glide displays results such as Data Source Verification, Risk Check, Document Verification, Selfie Check, and Watchlist Screening when those results are available.
Limited failure detail: Glide may show a failed Risk Check or a general reason such as “Risk Check failed.” or “Fraud checks require manual review.” It does not currently show a dedicated custom-rule result with the group name, exact condition, or matched value.

Investigate in Plaid: Use Open IDV in Plaid from Glide’s verification area and inspect the relevant session. Passing individual KYC/document checks does not establish that the overall session passed. Record your review and make the application decision through your normal Glide process.

Limits and common mistakes

History and group limits: Plaid’s current IDV documentation lists six months of Protect history and up to 30 custom rule groups.
Field availability varies: A field appearing in the picker does not guarantee it is populated or available at the point your rule runs. IDV, document, selfie, Link, bank-account, and network fields depend on the products, steps, and data collected.
Handle missing values deliberately: Use Exists / Does not exist where offered and test sessions with missing data. Do not assume “not equal to” is a reliable substitute for checking that a value exists.
Match the actual identifier: session.ip.geo.country is IP location; user.pi.address.country is the user’s address country. The two can differ. Likewise, the plain email field is not an email-domain field.
Scope is explicit: Configure each relevant customer team and template. Do not assume a parent/reseller group or one template’s changes automatically apply to another customer or flow.

Complete attribute reference

The rule builder offers: 206 attributes: 109 Session, 76 User, and 21 Event. The lists below include every field exposed in those categories during the walkthrough, with the dashboard’s description. Available fields and operators may change by account, product access, or Plaid release. The live picker is the source of truth.

Session attributes (109)

Attribute	Dashboard description
`session.bank_connections.app_connections__banking.count_7d`	Number of banking app connections for this Link session in the past 7 days
`session.bank_connections.app_connections__bfm.count_7d`	Number of business financial management app connections for this Link session in the past 7 days
`session.bank_connections.app_connections__consumer_payments.count_7d`	Number of consumer payments app connections for this Link session in the past 7 days
`session.bank_connections.app_connections__crypto.count_7d`	Number of crypto app connections for this Link session in the past 7 days
`session.bank_connections.app_connections__fintech.count_7d`	Number of fintech app connections for this Link session in the past 7 days
`session.bank_connections.app_connections__lending.count_7d`	Number of lending app connections for this Link session in the past 7 days
`session.bank_connections.app_connections__pfm.count_7d`	Number of personal financial management app connections for this Link session in the past 7 days
`session.bank_connections.app_connections__tech.count_7d`	Number of technology app connections for this Link session in the past 7 days
`session.bank_connections.app_connections__wealth.count_7d`	Number of wealth app connections for this Link session in the past 7 days
`session.bank_connections.app_connections.count_7d`	Total number of app connections for this Link session in the past 7 days
`session.bank_connections.app_connections.last.days_since`	Days since last connection
`session.bank_connections.bank_accounts.count`	Count of the number of unique bank accounts connected in this Link session. E.g. if the user connected a savings and credit card accounts from Chase and a checking account with Chime, the count would be three
`session.bank_connections.bank_accounts.txns.first.days_since`	Number of days since the first transaction on linked bank accounts.
`session.bank_connections.bank_accounts.txns.last.days_since`	Number of days since the last transaction on linked bank accounts.
`session.bank_connections.bank_accounts.txns.max_days_since_oldest`	Approximate age in days of oldest linked account: oldest linked account is at least {value} days or older
`session.bank_connections.bank_accounts.txns.min_days_since_oldest`	Approximate age in days of youngest linked account: youngest linked account is at least {value} days or older
`session.bank_connections.banks.names`	The names of financial institutions linked during this Link session.
`session.bank_connections.primary_pi.addresses.geo.max_miles_to_ip_geo`	Maximum distance in miles from the session IP address to bank account owner addresses.
`session.bank_connections.primary_pi.addresses.geo.min_miles_to_ip_geo`	Minimum distance in miles from the session IP address to bank account owner addresses.
`session.bank_connections.primary_pi.emails.match_user_pi`	Whether user's email matches linked bank account owners
`session.bank_connections.primary_pi.full_names.match_user_pi`	Whether user's name matches linked bank account owners
`session.bank_connections.primary_pi.match_user_pi`	Whether user's personal information matches linked bank account owners
`session.bank_connections.primary_pi.phones.match_user_pi`	Whether user's phone number matches linked bank account owners
`session.behavior.paste_events.count`	The count of paste events detected in Link inputs during the session.
`session.browser.compact_user_agent`	A compact version of the user agent string, which provides information about the browser and operating system used by.
`session.browser.is_incognito`	Whether the browser is in incognito mode
`session.device_id`	Plaid device identifier (dvc_) for this event's session.
`session.device.os`	Operating system of the device used in the event, such as iOS, Android, Windows, or macOS.
`session.device.sessions.link.login_attempts.mfa__failed.count_7d`	Number of failed multi-factor authentication events from this device's Link sessions in the past 7 days.
`session.duration_sec`	Duration in seconds from the first consumer interaction (session start) to the current event or session finish, whichever is earlier. Applies to both Link and IDV sessions.
`session.idv.datasource.address_count`	Number of address records found. A higher count may suggest a longer history or more varied residential addresses.
`session.idv.datasource.address_match_status`	The provided address matches records in US KYC records.
`session.idv.datasource.address_type`	Type of address used during US KYC checks. This categorizes the address as residential, commercial, or other types.
`session.idv.datasource.death_count`	Number of death records found. A non-zero count may indicate potential issues with identity verification.
`session.idv.datasource.dob_match_status`	The provided date of birth matches records in US KYC records.
`session.idv.datasource.family_name_match_status`	The provided last name matches records in US KYC records.
`session.idv.datasource.given_name_match_status`	The provided first name matches records in US KYC records.
`session.idv.datasource.identity_document_match_status`	The provided identity document matches records in US KYC records.
`session.idv.datasource.identity_document_number`	Document number of the identification document used during the Datasource step, such as a national ID or passport.
`session.idv.datasource.identity_document_type`	Type of identity document submitted (e.g., driver's license, passport, national ID card).
`session.idv.datasource.name_match_status`	The provided name matches records in US KYC records.
`session.idv.datasource.phone_area_code_match_status`	The provided phone area code matches records in US KYC records.
`session.idv.datasource.phone_carrier`	Carrier or service provider of the phone number found.
`session.idv.datasource.phone_count`	Number of phone records found. A higher count may suggest a longer history or more varied phone number usage.
`session.idv.datasource.phone_match_status`	The provided phone number matches records in US KYC records.
`session.idv.datasource.phone_type`	Type of phone number found during identity verification (e.g., landline, mobile, VoIP).
`session.idv.datasource.po_box_check`	The provided address is flagged as a PO Box during US KYC checks.
`session.idv.datasource.postal_code_match_status`	The provided postal code matches records in US KYC records.
`session.idv.datasource.ssn_count`	Number of SSN records found. A higher count may suggest a longer history or potential issues with SSN verification.
`session.idv.datasource.ssn_issue_place`	Geographical location where the SSN was originally issued, as found.
`session.idv.datasource.ssn_match_status`	Match status of the SSN provided during identity verification compared to datasource records.
`session.idv.datasource.step_status`	Status of the datasource verification step.
`session.idv.id`	Unique identifier of the identity verification session.
`session.idv.id_doc.dmv_address_match_status`	Result of comparing the address on ID document with the address in DMV records.
`session.idv.id_doc.dmv_dob_match_status`	Result of comparing the date of birth on ID document with the date of birth in DMV records.
`session.idv.id_doc.dmv_expiration_date_match_status`	Result of comparing the expiration date on ID document with the expiration date in DMV records.
`session.idv.id_doc.dmv_eye_color_match_status`	Result of comparing the eye color on ID document with the eye color in DMV records.
`session.idv.id_doc.dmv_family_name_match_status`	Result of comparing the last name on ID document with the last name in DMV records.
`session.idv.id_doc.dmv_given_name_match_status`	Result of comparing the first name on ID document with the first name in DMV records.
`session.idv.id_doc.dmv_id_number_match_status`	Result of comparing the ID number on document with the ID number in DMV records.
`session.idv.id_doc.dmv_issuance_date_match_status`	Result of comparing the issuance date on ID document with the issuance date in DMV records.
`session.idv.id_doc.dmv_name_match_status`	Result of comparing the full name on ID document with the name in DMV records.
`session.idv.id_doc.document_authenticity`	Result of document authenticity check. This assesses whether the document is genuine or potentially fraudulent.
`session.idv.id_doc.document_date_of_birth_status`	Verification status of the date of birth extracted from the identity document.
`session.idv.id_doc.document_detail_check`	Result of detailed document verification checks, including security features and document integrity validation.
`session.idv.id_doc.document_dimensions_check`	The identity document dimensions match expected standards for the document type. Values may include 'true' or 'false'
`session.idv.id_doc.document_expired`	The ID document is expired.
`session.idv.id_doc.document_extracted_data_visible`	The data extracted from ID document is clearly visible and readable.
`session.idv.id_doc.document_glare_check_passed`	The ID document passed the glare detection check. True means no problematic glare was detected.
`session.idv.id_doc.document_has_portrait`	The ID document has a portrait or photo.
`session.idv.id_doc.document_image_composition_check_passed`	The ID document image passed the composition quality check. This validates proper framing and positioning of document.
`session.idv.id_doc.document_image_quality`	Overall image quality assessment of ID document. Values are: 'high', 'medium', or 'low'.
`session.idv.id_doc.document_issuance_country`	Country that issued the ID document. This is typically represented as an ISO country code.
`session.idv.id_doc.document_number`	Document number of document used in the Documentary Verification step, such as a driver's license number or passport.
`session.idv.id_doc.document_portrait_presence_check`	Result of checking whether a portrait/photo is present on ID document.
`session.idv.id_doc.document_sharpness_check_passed`	The ID document image passed the sharpness quality check. True means the document image is sufficiently sharp and clear.
`session.idv.id_doc.document_type`	Type of document used in the Documentary Verification step, such as a driver's license or passport.
`session.idv.id_doc.document_upload_match`	The uploaded ID document matches the expected document format and requirements.
`session.idv.id_doc.is_resident_of_issuing_country`	Boolean result of determining whether the document holder is a resident of the country that issued the ID document.
`session.idv.id_doc.num_attempts`	Number of ID document submission attempts made.
`session.idv.id_doc.step_status`	Status of ID document verification step.
`session.idv.id_doc.user_selected_type`	Type of ID document that the user selected.
`session.idv.liveness.estimated_age_lower`	Lower bound of the estimated age range from the liveness check.
`session.idv.liveness.estimated_age_upper`	Upper bound of the estimated age range from the liveness check.
`session.idv.liveness.selfie_matches_doc`	The portrait from the liveness check selfie matches the portrait from ID document.
`session.idv.liveness.step_status`	Status of the liveness check step.
`session.idv.pi.email.social_networks__free.pct`	The percentage of social networks linked to the email that are free services.
`session.idv.pi.email.social_networks.count`	The number of social networks linked to the user's email address.
`session.idv.pi.phone.social_networks__free.pct`	The percentage of social networks linked to the phone that are free services.
`session.idv.pi.phone.social_networks.count`	The number of social networks linked to the user's phone number.
`session.idv.sms_check.num_attempts`	Number of SMS verification attempts made. Multiple attempts may suggest issues with SMS delivery or incorrect phone number entry.
`session.idv.sms_check.step_status`	Status of the SMS verification step.
`session.idv.status`	Overall status of the identity verification session
`session.idv.template.id`	Template ID used for the identity verification session workflow.
`session.idv.template.name`	Template name used for the identity verification session workflow.
`session.ip`	IPv4 address used during the session.
`session.ip.geo.city`	The city where the IP address is located based on geolocation data
`session.ip.geo.country`	The country where the IP address is located based on geolocation data
`session.ip.geo.country_code`	Country code associated with the user or event, typically in ISO 3166-1 alpha-2 format (e.g., US, CA, UK).
`session.ip.geo.latitude`	The latitude coordinate of the IP address's geographical location.
`session.ip.geo.location`	Geographical location of the event, typically in the form of a city or region.
`session.ip.geo.longitude`	The longitude coordinate of the IP address's geographical location.
`session.ip.geo.region`	State or region associated with the IP address used during the session.
`session.ip.is_vpn`	The IP address associated with the session is detected as a VPN or Virtual Private Network.
`session.link.id`	Unique identifier of the Plaid Link session.
`session.link.session_finish_status`	The status of the link session when it finished. Possible values are: STATUS_SUCCESS, STATUS_EXIT, STATUS_ERROR, or STATUS_UNKNOWN.
`session.location_spoofing_detected`	Location spoofing was detected during the session.
`session.mfa.challenged`	The user was challenged with multi-factor authentication.
`session.mfa.passed`	The multi-factor authentication challenge was successfully passed.

User attributes (76)

Attribute	Dashboard description
`user.bank_connections.app_connections__banking.count_7d`	Number of banking app connections for the user in the past 7 days
`user.bank_connections.app_connections__bfm.count_7d`	Number of business financial management app connections for the user in the past 7 days
`user.bank_connections.app_connections__consumer_payments.count_7d`	Number of consumer payments app connections for the user in the past 7 days
`user.bank_connections.app_connections__crypto.count_7d`	Number of crypto app connections for the user in the past 7 days
`user.bank_connections.app_connections__fintech.count_7d`	Number of fintech app connections for the user in the past 7 days
`user.bank_connections.app_connections__lending.count_7d`	Number of lending app connections for the user in the past 7 days
`user.bank_connections.app_connections__pfm.count_7d`	Number of personal financial management app connections for the user in the past 7 days
`user.bank_connections.app_connections__tech.count_7d`	Number of technology app connections for the user in the past 7 days
`user.bank_connections.app_connections__wealth.count_7d`	Number of wealth app connections for the user in the past 7 days
`user.bank_connections.app_connections.count_7d`	Total number of app connections for the user in the past 7 days
`user.bank_connections.app_connections.first.days_since`	Number of days since the first bank account connection associated with this user. Lower values indicate more recent first connections.
`user.bank_connections.app_connections.last.days_since`	Number of days since the most recent bank account connection associated with this user.
`user.bank_connections.app_connections.users.count`	Number of users that have linked one of this user's bank accounts.
`user.bank_connections.bank_accounts__closed.count`	Number of closed bank accounts associated with the user. Higher values may indicate account management patterns or issues with financial institutions.
`user.bank_connections.bank_accounts__frozen_or_restricted.count`	Number of frozen or restricted bank accounts associated with the user.
`user.bank_connections.bank_accounts.count`	Count of the number of unique bank accounts connected by this user. E.g. if the user connected a savings and credit card accounts from chase and a checking account with Chime, the count would be three
`user.bank_connections.bank_accounts.days_since_opening.max`	Maximum number of days since any bank account associated with the user was opened.
`user.bank_connections.bank_accounts.days_since_opening.min`	Minimum number of days since any bank account associated with the user was opened.
`user.bank_connections.bank_accounts.last.account_id`	This attribute contains the account ID of the most recently connected bank account by the user.
`user.bank_connections.bank_accounts.last.item_id`	This attribute contains the item ID of the most recently connected bank account by the user.
`user.bank_connections.bank_accounts.txns.max_days_since_oldest`	Approximate age in days of oldest linked account across all linked bank accounts for this user: oldest linked account is at least {value} days or older
`user.bank_connections.bank_accounts.txns.min_days_since_oldest`	Approximate age in days of youngest linked account across all linked bank accounts for this user: youngest linked account is at least {value} days or older
`user.bank_connections.banks.ato_rate_7d`	Rate of this user's connections flagged as account takeover in the past 7 days
`user.bank_connections.banks.count`	Total number of different banks with connected accounts
`user.bank_connections.banks.names`	The bank names for this user's linked bank accounts
`user.bank_connections.primary_pi.emails.count`	Total unique owner email addresses across accounts
`user.bank_connections.primary_pi.emails.match_user_pi`	Whether user's email matches all linked bank account owners
`user.bank_connections.primary_pi.full_names.count`	Total unique owner full names across accounts
`user.bank_connections.primary_pi.full_names.match_user_pi`	Whether user's name matches all linked bank account owners
`user.bank_connections.primary_pi.match_user_pi`	Whether user's personal info matches all linked bank account owners
`user.bank_connections.primary_pi.phones.count`	Total unique owner phone numbers across accounts
`user.bank_connections.primary_pi.phones.match_user_pi`	Whether user's phone matches all linked bank account owners
`user.client_user_id`	A unique ID representing the end user, typically the user ID from your application. Also known as the customer reference.
`user.id`	Unique identifier of the user. User IDs conform to this regex.
`user.pi.address`	User's complete address as provided in their personal information.
`user.pi.address.city`	City component of the user's address.
`user.pi.address.city_matches_records`	Whether user's city matches known records
`user.pi.address.country`	Country component of the user's address.
`user.pi.address.region`	State or region component of the user's address.
`user.pi.age`	This represents the age of the user, calculated in years.
`user.pi.date_of_birth`	Date of birth of the user.
`user.pi.email`	Email address associated with the user or event.
`user.pi.email.domain_badness_ratio`	Reputation score of the email domain
`user.pi.email.domain_is_custom`	Whether email domain is custom (not common provider)
`user.pi.email.history_yrs`	Years the email address has been in use
`user.pi.email.is_deliverable`	Whether email can receive messages
`user.pi.email.is_disposable`	Whether email is from disposable service
`user.pi.email.match_score_to_historic_emails`	Score matching current email to historical patterns
`user.pi.email.provider_is_free`	Whether email provider is free service
`user.pi.family_name`	Family name of the user.
`user.pi.full_name`	Full name of the user.
`user.pi.given_name`	Given name of the user.
`user.pi.phone`	Phone number associated with the user or event.
`user.pi.phone.days_since_updated`	Days since phone information was updated
`user.pi.ssn`	Social Security Number (SSN) of the user.
`user.pi.ssn.may_belong_to_a_minor`	Whether SSN may belong to a minor
`user.pi.ssn.user_likely_has_better_ssn`	Whether user likely has a more accurate SSN
`user.related_users.count`	Number of distinct users related to this user via PII connections.
`user.related_users.num_of_facial_duplicates`	Number of other IDV sessions whose selfie matched this user's face. A non-zero count may indicate an attempt to enroll multiple identities with the same face.
`user.related_users.reports.count`	Total number of Protect reports filed for users related to this user.
`user.related_users.reports.last.days_since`	Number of days since the most recent Protect report was filed for any user related to this user.
`user.related_users.reports.last.type`	Type of the most recent Protect report filed for any user related to this user.
`user.reports.count`	Total number of Protect reports filed for this user.
`user.reports.last.days_since_creation`	Number of days since the most recent Protect report was filed for this user.
`user.reports.last.type`	Type of the most recent Protect report filed for this user.
`user.sessions__link.browsers.user_agents.count_7d`	Number of distinct user agents used in Link sessions over the past 7 days.
`user.sessions.idv.last.datasource.status`	Datasource verification status from the latest IDV session for this user.
`user.sessions.idv.last.id_doc.attempts.count`	Number of document upload attempts made from the latest IDV session for this user.
`user.sessions.idv.last.id_doc.status`	Document verification status from the latest IDV session for this user.
`user.sessions.idv.last.liveness.status`	Liveness check verification status from the latest IDV session for this user.
`user.sessions.idv.last.sms_check.status`	SMS verification status from the latest IDV session for this user.
`user.sessions.ips.asns.count_7d`	Number of distinct Internet Service Provider (ASN) names used in Link sessions over the past 7 days.
`user.sessions.ips.count_7d`	Number of distinct IPv4 addresses used in Link sessions over the past 7 days.
`user.sessions.link__bot_detected.pct_7d`	Percentage of Link sessions flagged by bot detection over the past 7 days.
`user.sessions.link.first.days_since`	Number of days since the user's first Link session. Lower values suggest newer users to the platform.
`user.sessions.link.last.days_since`	Number of days since the user's most recent Link session. Lower values suggest more recent platform activity.

Event attributes (21)

Attribute	Dashboard description
`event.full_graph_9hop.app_connections.apps.count_30d`	Total number of unique client applications that have successfully connected bank accounts in the full 9-hop graph traversal in the past 30 days.
`event.full_graph_9hop.app_connections.apps.count_365d`	Total number of unique client applications that have successfully connected bank accounts in the full 9-hop graph traversal in the past 365 days.
`event.full_graph_9hop.app_connections.apps.count_7d`	Total number of unique client applications that have successfully connected bank accounts in the full 9-hop graph traversal in the past 7 days.
`event.full_graph_9hop.app_connections.count_30d`	Total number of unique bank account connections in the full 9-hop graph traversal in the past 30 days.
`event.full_graph_9hop.app_connections.count_365d`	Total number of unique bank account connections in the full 9-hop graph traversal in the past 365 days.
`event.full_graph_9hop.app_connections.count_7d`	Total number of unique bank account connections in the full 9-hop graph traversal in the past 7 days.
`event.full_graph_9hop.app_connections.first.days_since`	Days since the first app connection in the full 9-hop graph traversal.
`event.full_graph_9hop.app_connections.last.days_since`	Days since the last app connection in the full 9-hop graph traversal.
`event.full_graph_9hop.app_connections.users.count_30d`	Total number of unique users connected in the full 9-hop graph traversal in the past 30 days.
`event.full_graph_9hop.app_connections.users.count_365d`	Total number of unique users connected in the full 9-hop graph traversal in the past 365 days.
`event.full_graph_9hop.app_connections.users.count_7d`	Total number of unique users connected in the full 9-hop graph traversal in the past 7 days.
`event.full_graph_9hop.bank_connections.security_notifications__disconnect.pct_7d`	Percentage of security notification reports in the full 9-hop graph traversal that were disconnect reports over the past 7 days.
`event.full_graph_9hop.bank_connections.security_notifications.count_7d`	Number of security notification reports in the full 9-hop graph traversal over the past 7 days.
`event.full_graph_9hop.sessions__link.count`	Total number of unique Plaid sessions connected to the user in the full 9-hop graph traversal.
`event.full_graph_9hop.sessions.devices.count`	Total number of unique devices connected to the user in the full 9-hop graph traversal.
`event.id`	Unique event identifier.
`event.timestamp`	Timestamp when the event happened.
`event.trust_index_model_name`	The name and version of the trust index model used to generate the trust index score for this event.
`event.trust_index_score`	Trust index score of a given event, which is a numeric value indicating the trustworthiness of the event and its underlying user.
`event.trust_level`	Trust level of a given event: low, medium, high, or unknown. Trust level indicates the trustworthiness of the event and its underlying user.
`event.type`	Type of event that occurred, such as login, transaction, or document verification.