Sprint Duration: February 16 – March 6, 2026
Release Date to Production: Monday, April 6th, 2026
Quick Peek – What We Delivered
Sprint 2.3.1 focused on stabilizing core BCID workflows, improving vetting automation, correcting email and reference verification behaviors, and introducing key infrastructure improvements to APIs and webhook security.
During this sprint we:
Fixed incorrect BCID email notifications during the vetting process
Resolved a Display Identity approval issue where telephone numbers were not persisted
Improved internal reference verification handling and email formatting
Added clearer error handling for LOA template downloads
Implemented API payload standardization using Parent ID and Deal ID
Updated webhook payloads to follow the same identity structure
Introduced enterprise-grade webhook authentication (HMAC-SHA256)
Added a Webhook Security management section in the portal for OSPs
Improved automated EIN verification handling during application resubmissions
Conducted a platform scalability and infrastructure capacity assessment
Some of these improvements were critical and were released as hotfixes directly to production during the first week of March.
Detailed Changes
1. BCID Vetting Email Notification Fix
We identified a scenario where the platform could send conflicting email notifications during the vetting process.
In certain cases, the platform triggered multiple emails within minutes, including:
Two Action Required emails
A Rejected email
An Approved email
Even though the BCID application was still flagged in the portal.
To resolve this, we updated the email notification logic so that messages now strictly reflect the actual vetting outcome.
The platform will now:
Send only flagged step notifications if the application has flagged steps
Send approval emails only when the application is fully approved
Send rejection notifications only when the application is rejected
Prevent duplicate Action Required emails
This ensures that email notifications always match the actual status displayed in the portal, eliminating confusion during the vetting process.
2. Display Identity Change Request – Approval Persistence Fix
We resolved a high-severity issue where a Display Identity change request could appear approved even though the telephone number was not persisted in the backend.
This created a mismatch between the approval shown in the UI and the actual Display Identity configuration.
To resolve this, we implemented additional backend validation to ensure that:
Telephone numbers are fully persisted before approval confirmation is issued
Approval notifications are sent only after the update is successfully stored
Backend failures cannot silently mark a change request as completed
Once a change request is approved, the Display Identity will now accurately reflect the approved configuration.
3. Internal Reference Email Personalization Fix
We fixed an issue affecting the reference verification emails sent during Step 6 of the BCID application process.
Previously, these emails did not always display the correct recipient name, which could create confusion for internal references receiving the verification request.
Reference verification emails now correctly include the name of the specific individual receiving the email.
For example:
If Reference 1 is John, the email will address John
If Reference 2 is Maria, the email will address Maria
This improvement ensures that internal references clearly understand they were listed as a verification contact and helps prevent delays in completing the verification process.
4. Improved Reference Verification Handling in Vetting Queue
We improved how the platform handles reference verification status during the vetting process.
When internal references have not yet verified their identity, Step 6 will automatically be flagged with a comment indicating that reference verification is still pending.
This provides immediate visibility to both:
OSP users
Vetting agents
If you see this flag under Step 6, it means that one or more internal references have not yet completed their email identity verification.
To avoid delays in the vetting process, please ensure your enterprise contacts verify their identity promptly after submitting the BCID application.
5. LOA Template Download Error Handling
We identified a scenario where users could receive an error when attempting to download the LOA template in Step 7 of the BCID application process.
This occurred when an OSP ID had not yet been configured in the portal.
To address this, the platform now displays a clear error message explaining why the template cannot be downloaded when an OSP ID is missing.
This situation typically only affects newly onboarded OSP accounts before their configuration is completed.
Existing OSP partners should not encounter this issue, as our team ensures that all required setup steps are completed during onboarding.
Hotfixes Released to Production
The following improvements were deployed as hotfixes during the first week of March to address issues requiring immediate resolution.
6. EIN Verification Handling Improvement
We resolved an issue affecting EIN verification when a BCID application was resubmitted with an updated EIN.
Previously, when an EIN was corrected and resubmitted, the platform could still display the verification as pending, creating confusion during the vetting process.
With this fix, when an EIN is updated and resubmitted, the platform now:
Immediately triggers verification for the updated EIN
Processes the new EIN without unnecessary delays
This ensures that corrected EIN information is verified quickly and efficiently, allowing applications to proceed through the vetting process smoothly.
7. API Identity Model Standardization
As part of our effort to remove ambiguity between OSP-level and enterprise-level identifiers, we implemented an API update that standardizes how IDs are returned in payloads.
API responses now include both identifiers:
Parent ID – represents the OSP
Deal ID – represents the enterprise associated with the deal
Affected APIs include those related to:
Deal registration
BCID application submissions
Vetting outcomes
You may still see Client ID temporarily in API responses. However:
Client ID will be deprecated on March 31, 2026.
If your integrations currently rely on Client ID, please begin transitioning to Parent ID and Deal ID.
This update establishes a clear parent-child relationship between OSPs and enterprise clients, simplifying integrations and improving data reconciliation.
8. Webhook Payload Identity Standardization
Webhook payloads have been updated to follow the same identity structure as the APIs.
The following webhooks now include both Parent ID and Deal ID:
Deal Registration Webhook
BCID Application Submission Webhook
Vetting Review Webhook
Display Identity Webhook
This ensures consistent identity structure across both APIs and webhook notifications.
9. Mandatory Webhook Security Standard – HMAC-SHA256
We implemented a new HMAC-SHA256 webhook authentication standard across the platform.
This introduces a more secure model for webhook integrations, including:
API key identification
Secret-based cryptographic signatures
Timestamp validation
Delivery ID tracking for retries
This upgrade strengthens webhook security by preventing:
Replay attacks
Spoofed webhook deliveries
Unauthorized webhook calls
10. New Webhook Security Section in the Portal
A new Webhook Security section has been added to the white-label portal.
From this section, OSP users can:
Generate webhook API credentials
View their API key and secret
Regenerate credentials
Delete credentials if needed
This section is designed for OSP partners who want to receive webhook notifications from the platform.
If you are interested in enabling webhook notifications, please contact our team and we will help guide you through the setup process.
Platform Load & Capacity Assessment (Spike)
During this sprint, we conducted a technical assessment of the platform’s infrastructure and scalability.
This analysis included reviewing:
Storage usage
API call volume
Infrastructure capacity
System growth projections
The outcome of this assessment will guide future architectural improvements to ensure the platform remains stable, performant, and scalable as adoption grows.
Why It Matters to You
More reliable BCID status notifications
Faster EIN verification handling
Accurate Display Identity change approvals
Clearer API identity structure
Consistent API and webhook payloads
Stronger webhook authentication security
Improved vetting workflow visibility
Better platform scalability planning
Questions or Feedback
For questions about APIs, integrations, or webhooks, please contact:
Daniela Villamar
dvillamar@numhub.com
Comments
0 comments
Please sign in to leave a comment.