> ## Documentation Index
> Fetch the complete documentation index at: https://docs.pylon.mortgage/llms.txt
> Use this file to discover all available pages before exploring further.

# Day 1 Certainty & AIM overview

> Learn about Day 1 Certainty (D1C) and Asset and Income Modeler (AIM), automated verification systems that eliminate manual data entry and reduce documentation requirements.

**Day 1 Certainty (D1C)** and **Asset and Income Modeler (AIM)** are automated verification systems approved by Fannie Mae and Freddie Mac that enable programmatic loan origination with minimal borrower friction and reduced documentation requirements.

For detailed information about what D1C and AIM are, their benefits, how they work, approved vendors, and best practices, see the [D1C and AIM glossary entry](/entity-models/key-concepts/d1c-aim).

## Available integrations

Pylon currently supports the following D1C and AIM approved sources:

* **[Truv](/guides/getting-started/order-outs-and-integrations/d1c-aim/income-verification)** - Income, employment, and asset verification (D1C and AIM approved)
* **[The Work Number](/guides/getting-started/order-outs-and-integrations/d1c-aim/income-verification)** - Income and employment verification (D1C and AIM approved)
* **[Plaid](/guides/getting-started/order-outs-and-integrations/d1c-aim/asset-verification)** - Asset verification (D1C and AIM approved for assets)

## When to use D1C and AIM

Use D1C and AIM approved sources whenever possible to reduce documentation requirements and accelerate loan processing. Pylon automatically attempts automated verification through available vendors, falling back to traditional documentation methods when automated verification isn't available.

## Pylon's unified vendor integration API

Pylon provides a **unified, vendor-agnostic API** for integrating with D1C and AIM approved verification services. Instead of integrating directly with multiple vendors (Plaid, Truv, The Work Number), you use a single Pylon API that handles vendor selection, credential management, data mapping, and entity hydration.

### Why Pylon abstracts vendor integrations

Without Pylon's unified API, you would need to:

1. **Integrate with each vendor separately**: You'd need to build integrations with Plaid, Truv, The Work Number, and any future vendors—doing the same work N times for N vendors.

2. **Manually map vendor responses**: Each vendor returns data in different formats. You'd need to map Plaid's asset data, Truv's income data, and The Work Number's employment data to Pylon's entity model (incomes, assets, etc.) yourself.

3. **Trust and verification gaps**: If you integrated directly with vendors and posted that information to us, Pylon would need to trust if it came from D1C/AIM approved sources. This creates gaps in:
   * **Rep and warrant relief**: Pylon needs to know the specific source and certification details to provide rep and warrant relief through [AUS (Automated Underwriting System)](/entity-models/key-concepts/aus) integration.
   * **Data provenance**: Without knowing the source, Pylon can't verify that data meets D1C/AIM requirements through [AUS](/entity-models/key-concepts/aus).

4. **Credential management complexity**: You'd need to manage credentials for each vendor, handle webhook configurations, and maintain vendor-specific integration logic.

### The Pylon solution

Pylon's unified API solves these problems:

* **Single integration point**: One API handles all vendors—you don't need separate integrations for Plaid, Truv, or The Work Number.
* **Automatic data mapping**: Pylon handles all vendor response mapping to Pylon entities (incomes, assets, etc.). You simply poll Pylon for the hydrated entities.
* **Built-in certification tracking**: Pylon tracks vendor reference IDs, certification details, and data provenance automatically, enabling rep and warrant relief.
* **Credential management**: As a reseller, Pylon manages vendor credentials on your behalf (though you can still use your own credentials for other use cases).

<Info>
  **Reseller model**: Pylon is a reseller for Plaid and Truv, meaning Pylon provisions and manages customer-specific credentials. This doesn't prevent you from using your own credentials for other use cases (e.g., you can still pull detailed borrower income data directly from a vendor's API for your own purposes).
</Info>

### How the integration works

The vendor integration process follows a consistent pattern across all vendors:

<Steps>
  <Step title="Request initialization token">
    You request a vendor-specific initialization token from Pylon for a borrower. Pylon returns a token (e.g., `linkToken` for Plaid, `bridgeToken` for Truv) that you use to initialize the vendor's frontend widget.
  </Step>

  <Step title="Initialize vendor widget">
    Use the token to initialize the vendor's frontend component ([Plaid Link](https://plaid.com/docs/link/) for Plaid, Truv Bridge for Truv) in your application. The borrower authenticates and connects their accounts through the vendor's UI.
  </Step>

  <Step title="Widget exchanges public token">
    After the borrower completes the flow, the vendor widget calls `onSuccess` callback that you provide with a `publicToken`. You must call Pylon's `exchangePublicToken` mutation from within this callback to establish permanent access to those accounts. This exchange converts the temporary `publicToken` into a permanent `accessToken` and `itemId`/`linkId`.
  </Step>

  <Step title="Pylon handles data retrieval">
    Pylon automatically retrieves verified data from the vendor asynchronously. This includes assets (from Plaid), income and employment (from Truv), and other verified information.
  </Step>

  <Step title="Poll for hydrated entities">
    Once data is retrieved, Pylon maps vendor responses to Pylon entities (incomes, assets, etc.) and hydrates them automatically. You simply poll Pylon's GraphQL API for these entities—no vendor-specific mapping required.
  </Step>
</Steps>

### API structure

#### Create initialization token

Request a token to initialize a vendor's frontend widget for a borrower:

```graphql theme={null}
mutation CreateInitializationToken($input: CreateInitializationTokenInput!) {
  verify {
    createInitializationToken(input: $input) {
      ... on PlaidLinkToken {
        linkToken
      }
      ... on TruvBridgeToken {
        bridgeToken
      }
    }
  }
}
```

**Input:**

* `vendor`: The vendor to use (`PLAID` or `TRUV`)
* `borrowerId`: The ID of the borrower who will authenticate

**Response:**

* For Plaid: Returns `linkToken` to initialize [Plaid Link](https://plaid.com/docs/link/)
* For Truv: Returns `bridgeToken` to initialize Truv Bridge

#### Exchange public token

After the borrower completes the flow in the vendor widget, the widget automatically exchanges the `publicToken` with Pylon via the `onSuccess` callback that you provide is as a parameter to the widget. The widget handles the exchange automatically, however you need to call the exchange mutaiton from within the callback:

```graphql theme={null}
mutation ExchangePublicToken($input: ExchangePublicTokenInput!) {
  verify {
    exchangePublicToken(input: $input) {
      ... on PlaidItemAccess {
        itemId
        accessToken
      }
      ... on TruvLinkAccess {
        linkId
        accessToken
      }
    }
  }
}
```

**Input:**

* `vendor`: The vendor (`PLAID` or `TRUV`)
* `publicToken`: The token provided by the vendor widget in the `onSuccess` callback after successful authentication

**Response:**

* For Plaid: Returns `itemId` and `accessToken` (Plaid creates one Item per institution)
* For Truv: Returns `linkId` and `accessToken` (Truv creates one Link per institution)

<Info>
  **Automatic exchange**: The widget handles the exchange automatically via the `onSuccess` callback. You simply provide the callback function when initializing the widget—the exchange happens behind the scenes.
</Info>

<Info>
  **Multiple institutions**: Both Plaid and Truv create separate Items/Links per institution. If a borrower has accounts at Chase and Citi, they'll need to complete the authentication flow separately for each, creating multiple Items/Links.
</Info>

#### Polling for hydrated entities

Once Pylon receives verified data from vendors, it automatically:

1. **Maps vendor responses** to Pylon entity structures (incomes, assets, etc.)
2. **Tracks certification metadata** including vendor, reference ID, and certification status internally
3. **Hydrates entities** in your loan file

You don't need to:

* Parse vendor-specific response formats
* Map vendor fields to Pylon entities
* Handle certification tracking
* Manage vendor reference IDs

Simply poll Pylon's GraphQL API for incomes, assets, and other entities as you normally would. For detailed information on querying incomes and assets, including GraphQL query examples and Node.js/TypeScript polling implementations, see:

* [Income Verification - GraphQL Query Example](/guides/getting-started/order-outs-and-integrations/d1c-aim/income-verification#graphql-query-example) - Learn how to query verified income data
* [Asset Verification - GraphQL Query Example](/guides/getting-started/order-outs-and-integrations/d1c-aim/asset-verification#graphql-query-example) - Learn how to query verified asset data

<Info>
  **Verified data**: When data is verified through D1C/AIM approved sources, Pylon automatically populates the `verifiedAmount` field on incomes and uses the `amount` field on assets. Pylon tracks vendor reference IDs and certification details internally for rep and warrant relief and [AUS](/entity-models/key-concepts/aus) integration—you don't need to manage this metadata.
</Info>

### Best practices

1. **Prioritize automated verification**: Always attempt automated verification through D1C/AIM approved sources before requesting traditional documentation. This reduces conditions and speeds up processing.

2. **Implement vendor waterfall**: Since not all vendors have coverage for every institution or payroll provider, you should implement a vendor waterfall strategy to maximize verification success. See the [D1C and AIM glossary](/entity-models/key-concepts/d1c-aim#vendor-waterfall-strategy) for more details on why vendor waterfalls are important and how to approach them.

3. **Request tokens on-demand**: Request initialization tokens when borrowers are ready to authenticate, not in advance.

4. **Handle multiple institutions**: Be prepared for borrowers to authenticate multiple institutions (each creates a separate Item/Link).

5. **Poll for entities**: After exchanging public tokens, poll Pylon's GraphQL API for incomes and assets rather than trying to track vendor-specific status. See the [Income Verification](/guides/getting-started/order-outs-and-integrations/d1c-aim/income-verification) and [Asset Verification](/guides/getting-started/order-outs-and-integrations/d1c-aim/asset-verification) pages for details on querying verified data.

6. **Display verified data**: When displaying verified data, check for the presence of `verifiedAmount` on incomes or verified `amount` on assets to indicate that data is verified through D1C/AIM approved sources.

7. **Handle failures gracefully**: If vendor authentication fails or data isn't available, fall back to traditional verification methods (document upload, manual entry).

## Related resources

* [D1C and AIM Glossary](/entity-models/key-concepts/d1c-aim) - Detailed information about Day 1 Certainty and Asset and Income Modeler programs
* [Income Verification](/guides/getting-started/order-outs-and-integrations/d1c-aim/income-verification) - Learn about The Work Number and Truv integration
* [Asset Verification](/guides/getting-started/order-outs-and-integrations/d1c-aim/asset-verification) - Learn about Plaid integration
* [Order-Outs Overview](/guides/getting-started/order-outs-and-integrations/overview) - Understand when automated verifications are triggered