Bundle 3 — Receive ID, Check Client Eligibility and Receive Credit Committee Report Data upon Questionnaire Submit
Trigger: Questionnaire submitted in YAPU
Business purpose
Bundle 3 adds a pre-screening step to the questionnaire workflow. Before a loan officer invests time completing a full YAPU questionnaire, your system is consulted to determine whether the customer is eligible to proceed — for example, by checking against an exclusion list or blacklist. If the customer is not eligible, the questionnaire is stopped immediately and no data is saved. This protects loan officer time, ensures compliance with client-defined eligibility rules, and prevents ineligible applicants from progressing through the credit cycle.
Capabilities
- Eligibility gate: YAPU queries your system with the customer ID before the questionnaire proceeds
- Early termination: If the customer is marked ineligible, the questionnaire ends immediately — no data is recorded
- Outbound CCR data: For eligible customers, Credit Committee Report data is sent to your system on submission
How it works
- A loan officer opens a questionnaire in YAPU and answers the "ID number" question.
- YAPU sends Data Set A (the customer ID) to the client system.
- The client system evaluates eligibility and returns a response (Data Set B.1 or B.2).
- Not eligible (B.1): YAPU displays a message to the loan officer that the customer is not eligible. The questionnaire ends immediately — no data is saved.
- Eligible (B.2): The questionnaire proceeds normally.
- The officer completes, finalizes, and presses Submit.
- YAPU sends Data Set C (CCR output data) to the client system.
Data exchange
| Direction | Data set | Content |
|---|---|---|
| Outbound (YAPU → Client) | Data Set A | Customer identification number entered by the loan officer |
| Inbound (Client → YAPU) | Data Set B.1 | Pre-defined signal: customer is not eligible — questionnaire is terminated |
| Inbound (Client → YAPU) | Data Set B.2 | Pre-defined signal: customer is eligible — questionnaire continues |
| Outbound (YAPU → Client) | Data Set C | Configurable selection of questionnaire and Credit Committee Report fields |
:::info Data format Inbound eligibility signals (Data Set B.1 and B.2) must use the YAPU-specific pre-defined format. Outbound data is delivered as JSON strings. :::
When to use Bundle 3
Bundle 3 is the right choice when:
- Your institution has exclusion lists, blacklists, or eligibility rules that must be checked before a credit assessment begins
- You want to prevent ineligible customers from appearing in YAPU at all
- You do not need to autofill the questionnaire with customer data from your system
- Submit is the only event that should trigger outbound data delivery
If you also need questionnaire autofill on top of the eligibility check, consider Bundle 6 (which combines both). If you need additional triggers on update or approval, consider Bundle 9 or Bundle 10.
Limitations
- Requires a YAPU questionnaire already configured for the integration
- Only a single questionnaire can be used per integration
- The eligibility response format must conform to the YAPU pre-defined specification
- When a customer is rejected at the eligibility gate, no questionnaire data is recorded in YAPU — this is by design
- Connectivity between YAPU and the client system must be available at the time the ID is entered; without connectivity the questionnaire cannot proceed
Related bundles
| Bundle | Relationship |
|---|---|
| Bundle 1 | Bundle 3 without the eligibility check |
| Bundle 2 | Uses ID lookup for autofill instead of eligibility check |
| Bundle 6 | Bundle 3 + additional trigger on update |
| Bundle 9 | Bundle 3 + additional trigger on "Approval" |
| Bundle 10 | Bundle 3 + all additional triggers (update + Approval) |
:::tip Ready to integrate? Contact your YAPU representative to confirm whether Bundle 3 matches your use case and to begin the specification process. See Integration Process for timelines and next steps. :::