Identifee with your Q2 data.

Identifee is a back-office platform for your staff — a CRM and engagement workspace used by relationship managers, treasury and commercial teams, branch and retail staff, marketing, and leadership. It brings account, relationship, and activity data into one place so your people can see the full picture of a relationship without moving between systems.

Your account holders never see or use Identifee. It is not a member- or customer-facing application. It does not appear inside online banking or your mobile app, it is not linked from them, and account holders are never asked to create an Identifee login. Nothing about the account holder's digital banking experience changes when your institution adopts Identifee.

Because Identifee sits behind your institution's walls, the questions that usually accompany a digital banking change — member communication, UI review, accessibility testing of a member-facing screen, app store releases — do not apply here. The integration is an internal data and staff-tooling project.

Identifee reads your Q2 data through EVE (Q2's data and analytics environment) and/or Q2's APIs, stores the results inside Identifee, and presents them to your staff in the Identifee application. The connection is read-only: Identifee consumes data from Q2 and never writes anything back to Q2.

What this means in practice

• One direction only. Data flows Q2 → Identifee. No balances, profiles, alerts, entitlements, or messages are created or changed in Q2 by Identifee.
• No change to online banking. Because Identifee only reads, the account holder experience in Q2 is untouched, and Identifee cannot affect an account holder's session or entitlements.
• Identifee is a copy, not the system of record. Q2 remains the system of record for digital banking data. Identifee holds a working copy for staff analysis and engagement.
• Separate access. Identifee access is provisioned and revoked by your institution independently of Q2 access.

Data refresh

Identifee refreshes its copy of your Q2 data on a recurring schedule agreed with your team during onboarding and recorded in your integration runbook. Every record in Identifee carries the timestamp of the refresh it came from, so staff can always see how current the data is. If a refresh does not complete, the previous data remains in place and is not silently discarded — see Support & escalation for what to do when data looks stale.

Identifee is built for institutions that are examined. The controls below apply to the data Identifee reads from Q2 and to everything else stored in your tenant.

Where data is stored

A secure cloud environment hosted in the United States, in a tenant dedicated to your institution and logically separated from every other customer.

Encryption

Encrypted in transit and at rest. Connections to Q2 and to Identifee use TLS; stored data is encrypted at rest.

Certification

SOC 2 Type II certified. The current report is available to your vendor management team under NDA, along with completed SIG or CAIQ questionnaires on request.

Third-party LLMs

Your data is not shared with third-party LLM providers and is not used to train third-party models. AI features operate within the Identifee environment against your approved data.

Access controls

Role-based access down to the record level, SSO/SAML support, and least-privilege internal access. Identifee personnel access is limited to support purposes and logged.

Audit logging

Data pulls, user sign-ins, and record access are logged and retained so activity can be reconstructed for examiners or internal audit.

Deletion on termination

On termination, your data is deleted from the Identifee environment, including backups, within the window set out in your agreement. Written confirmation of deletion is provided on request.

Credentials and connection security

• Q2/EVE credentials are issued by your institution, held in an encrypted secret store, and never written into application code, tickets, or email.
• Credentials are scoped to read-only access to the agreed data sets — nothing broader.
• Your institution can rotate or revoke the credentials at any time; revocation stops the data feed immediately and affects nothing else in Identifee.
• Where your policy requires it, connections can be restricted to allow-listed source addresses.

Sensitive data

The data set is scoped so Identifee receives what staff need to serve relationships and no more. If your policy requires certain fields to be excluded, masked, or truncated before they leave Q2, that is defined during scoping and enforced in the feed configuration.

There are two separate pieces of setup, and they can run in parallel: establishing the data feed with your IT team, and provisioning staff access to Identifee.

Establishing the EVE / API data feed

1. Scoping. Identifee and your digital banking and IT teams agree which Q2 data sets and fields are in scope, the refresh cadence, and any exclusions. The result is written down and approved before any connection is made.
2. Credentials. Your institution creates a dedicated, read-only service account or API credential for Identifee in EVE and/or the Q2 APIs. Where Q2's own process requires it, your Q2 relationship team enables the access on their side.
3. Secure handoff. Credentials and endpoints are shared through a secure channel — never plain email — and stored encrypted.
4. Connection test. Identifee runs a first pull against a limited data set and validates record counts, field mapping, and formats with your team.
5. Validation. Your team reviews a sample in Identifee against Q2 to confirm the data is complete and correct.
6. Go live. The scheduled refresh is enabled, monitoring is turned on, and the integration runbook — scope, cadence, contacts, escalation path — is handed to your team.

Provisioning staff access

• Administrators. Your institution names its own Identifee administrators. They add and remove users, assign roles, and set what each role can see — no ticket to Identifee required.
• Roles and permissions. Access is role-based; permissions can be scoped by team, portfolio, or record so staff see only the relationships they are responsible for.
• Single sign-on. Identifee supports SSO/SAML against your identity provider, so Identifee access follows your existing joiner-mover-leaver process.
• Offboarding. Removing a user in your identity provider (or in Identifee, if SSO is not used) revokes access immediately. Q2 access and Identifee access are managed separately, so removing one does not remove the other — offboarding checklists should include both.

Ongoing administration

Administrators can review who has access and what they can see at any time. Changes to the data feed's scope or cadence go through the same review as the original scoping, so the documented scope and the running configuration never drift apart.

Identifee supports this integration on a white-glove model: your institution has a named customer success manager and a named technical contact who know your configuration, rather than an anonymous queue. Onboarding, training, data-feed changes, and troubleshooting all run through the same people.

Who to contact

• Your staff raise issues with your institution's Identifee administrators first — most questions are about access or permissions, which your administrators control.
• Your administrators contact your Identifee customer success manager for anything they cannot resolve, including data questions and feature requests.
• Your IT team contacts your named Identifee technical contact directly for data-feed and connectivity issues.
• If you do not have those contacts to hand, reach us through the contact form and we will route you to your named team.

Support hours and response targets

Support is available during U.S. business hours, with escalation coverage for urgent issues. The specific hours and response targets that apply to your institution are set out in your service agreement and repeated in your integration runbook.

If the data feed breaks

Identifee monitors each scheduled pull. If a refresh fails, we are alerted, and your named technical contact reaches out with what failed and what is being done. You do not have to detect the outage for us to start working on it. A failed refresh does not remove data already in Identifee — staff keep working with the last successful pull.

What we ask from your side when a feed issue is raised:

• Confirm whether anything changed on the Q2 side — credential rotation, entitlement changes, an EVE or API upgrade, or a network or firewall change.
• Tell us when the data was last known to be correct.
• Give us a technical contact who can check the credential and connectivity with us.

If the data looks stale or wrong

1. Check the "last refreshed" timestamp on the record or view in question — the data may simply be from the last scheduled pull rather than live.
2. Compare a single record against Q2 to establish whether the issue is a stale refresh or a mapping problem.
3. Report it to your administrator with the record, the field, what Identifee shows, and what Q2 shows.
4. Your administrator escalates to your Identifee contact, who confirms whether the last refresh completed and, if the data is a mapping issue, corrects the mapping and re-runs the pull.