Skip to main content
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.

​
Available integrations

Pylon currently supports the following D1C and AIM approved sources:
  • Truv - Income, employment, and asset verification (D1C and AIM approved)
  • The Work Number - Income and employment verification (D1C and AIM approved)
  • Plaid - 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) integration.
    • Data provenance: Without knowing the source, Pylon can’t verify that data meets D1C/AIM requirements through 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).
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).

​
How the integration works

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

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.
2

Initialize vendor widget

Use the token to initialize the vendor’s frontend component (Plaid Link for Plaid, Truv Bridge for Truv) in your application. The borrower authenticates and connects their accounts through the vendor’s UI.
3

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.
4

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.
5

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.

​
API structure

​
Create initialization token

Request a token to initialize a vendor’s frontend widget for a borrower: 
mutation CreateInitializationToken($input: CreateInitializationTokenInput!) {
  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
  • 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: 
mutation ExchangePublicToken($input: ExchangePublicTokenInput!) {
  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)
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.
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.

​
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:
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 integration—you don’t need to manage this metadata.

​
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 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 and 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).