Bundle 11 — Check Client Eligibility with ID and Receive Credit Committee Report Data upon Submit, when Questionnaire/Report is Updated, or when Report Status Updates to "Approval"
Triggers: Questionnaire submitted or questionnaire/report updated or report status updated to "Approval" in YAPU
Business purpose
Bundle 11 is the most comprehensive standard bundle. It combines a customer eligibility gate with all three outbound trigger events — submission, update, and approval. Ineligible customers are stopped before any credit assessment begins, enforcing compliance rules and protecting loan officer time. For eligible customers, your system receives CCR data at every key point in the credit lifecycle: initial submission, any subsequent modification, and formal approval. No manual data transfer is required at any stage.
Capabilities
- Eligibility gate: YAPU checks your system before the questionnaire proceeds — ineligible customers are stopped immediately with no data recorded
- Outbound on submit: CCR data is pushed to your system when the questionnaire is submitted
- Outbound on update: CCR data is re-sent whenever the questionnaire or CCR report is modified
- Outbound on approval: CCR data is re-sent when the report status is set to "Approval"
- Maximum coverage across compliance, data synchronization, and credit decision automation
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 — Questionnaire or Report Update:
- A YAPU user opens the customer profile and modifies the questionnaire or CCR report. YAPU sends Data Set C again with updated values. This step can repeat as many times as needed until the CCR status reaches "Approved" or "Rejected".
Trigger 3 — Report Status Update "Approval":
- A YAPU user sets the report status to "Approval". YAPU sends Data Set C once more, reflecting the final approval.
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 questionnaire and CCR fields | On questionnaire or report update |
| Outbound (YAPU → Client) | Data Set C | 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. Your system should be prepared to receive multiple pushes for the same customer record across different trigger events. :::
When to use Bundle 11
Bundle 11 is the right choice when:
- Your institution enforces eligibility rules (exclusion lists, blacklists, risk filters) that must be respected before any credit assessment begins
- Your system must stay fully synchronized with YAPU across submission, revisions, and approval
- Downstream workflows need to act on both data changes and the formal credit decision event
- You want the most complete integration coverage available in the standard bundle catalog
If not all triggers are needed, consider a lighter bundle:
If you need autofill instead of an eligibility check with all triggers, see Bundle 10.
Limitations
- Requires a YAPU questionnaire already configured for the integration
- Only a single questionnaire can be used per integration
- Eligibility signals (B.1 and B.2) must conform to the YAPU pre-defined format
- When a customer fails the eligibility check, no questionnaire data is recorded — this is by design
- The update trigger can fire multiple times per record — your system should handle repeated pushes correctly
- The "Approval" trigger fires only when the report status is explicitly set to the designated approval value
- API connectivity must be available when the ID is entered for the eligibility check to function
Related bundles
| Bundle | Relationship |
|---|---|
| Bundle 6 | Bundle 11 without the approval trigger |
| Bundle 9 | Bundle 11 without the update trigger |
| Bundle 3 | Bundle 11 with submit-only trigger |
| Bundle 10 | Uses autofill instead of eligibility check, same triggers |
:::tip Ready to integrate? Contact your YAPU representative to confirm whether Bundle 11 matches your use case and to begin the specification process. See Integration Process for timelines and next steps. :::