Bundle 9 — Receive ID, Check Client Eligibility and Receive Credit Committee Report Data upon Questionnaire Submit OR upon Report Status Update "Approval"
Triggers: Questionnaire submitted or report status updated to "Approval" in YAPU
Business purpose
Bundle 9 combines the eligibility gate of Bundle 3 with the approval-based trigger of Bundle 7. Ineligible customers are stopped before the questionnaire begins, protecting loan officer time and enforcing compliance rules. For eligible customers, CCR data is delivered both at submission and at formal credit approval — enabling approval-driven automation in downstream systems such as loan origination or CBS updates.
Capabilities
- Eligibility gate: YAPU checks your system before the questionnaire proceeds; ineligible customers are stopped immediately
- Outbound on submit: CCR data is pushed to your system when the questionnaire is submitted
- Outbound on approval: CCR data is re-sent when the report status is set to "Approval" in YAPU
- Supports compliance enforcement and credit-decision automation in a single bundle
How it works
Questionnaire start — Eligibility check:
- A loan officer opens a questionnaire in YAPU and enters the customer ID.
- YAPU sends Data Set A (ID) to your system.
- Your system returns an eligibility signal:
- Not eligible (B.1): YAPU notifies the officer — questionnaire ends immediately, no data saved.
- Eligible (B.2): Questionnaire proceeds normally.
Trigger 1 — Submit:
- The officer completes, finalizes, and submits. YAPU sends Data Set C to your system.
Trigger 2 — Report Status Update "Approval":
- A YAPU user opens the customer's CCR and updates the status to "Approval".
- YAPU sends Data Set C again to your system, reflecting the updated approval status.
Data exchange
| Direction | Data set | Content | When |
|---|---|---|---|
| Outbound (YAPU → Client) | Data Set A | Customer identification number | On ID entry |
| Inbound (Client → YAPU) | Data Set B.1 | Eligibility signal: not eligible — questionnaire terminated | Response to ID lookup |
| Inbound (Client → YAPU) | Data Set B.2 | Eligibility signal: eligible — questionnaire continues | Response to ID lookup |
| Outbound (YAPU → Client) | Data Set C | Questionnaire and CCR fields | On submit |
| Outbound (YAPU → Client) | Data Set C | Updated CCR fields including approval status | On "Approval" status update |
:::info Data format Inbound eligibility signals (B.1 and B.2) must use the YAPU pre-defined format. All outbound data is delivered as JSON strings. :::
When to use Bundle 9
Bundle 9 is the right fit when:
- Your institution enforces eligibility rules that must be checked at the start of every credit assessment
- Downstream systems need to act specifically on a formal credit approval (not just submission)
- You do not need to autofill the questionnaire with customer data from your system
Consider Bundle 3 if the approval trigger is not needed. Consider Bundle 8 if you want autofill instead of eligibility checking, with the same triggers. Consider Bundle 10 for the most comprehensive combination, adding update-based triggers as well.
Limitations
- Requires a YAPU questionnaire already configured for the integration
- Only a single questionnaire can be used per integration
- Eligibility signals must conform to the YAPU pre-defined format
- When a customer fails the eligibility check, no data is recorded — this is by design
- The "Approval" trigger fires only when the report status is explicitly set to the designated approval value
- API connectivity must be available at the time the ID is entered for the eligibility check to function
Related bundles
| Bundle | Relationship |
|---|---|
| Bundle 3 | Bundle 9 with submit-only trigger |
| Bundle 7 | Bundle 9 without the eligibility check |
| Bundle 6 | Uses "update" as the second trigger instead of "Approval" |
| Bundle 8 | Uses autofill instead of eligibility check, same triggers |
| Bundle 10 | Bundle 9 + update trigger |
:::tip Ready to integrate? Contact your YAPU representative to confirm whether Bundle 9 matches your use case and to begin the specification process. See Integration Process for timelines and next steps. :::