Your team has completed a palm vein pilot and already enrolled users. Now you are preparing to use the Large Model.
Does every customer need to return and scan their palms again?
Where suitable palm images and the corresponding business user IDs have been retained, your team can use those records to register users through X-Telcom’s Large Scale registration API.
The documented approach is to create a script that submits a registration request for each user. This can avoid another palm capture session, provided the retained data meets the Large Model’s registration requirements.
However, this process creates registrations in a separate system. It does not merge the Small Model and Large Model databases.
1. Start by Checking What Your Project Has Saved
The first question is not how many users you have. It is whether you have the required registration inputs.
A list of Small Model feature IDs alone is not sufficient for the documented image-based registration process.
Your team needs suitable retained palm images and the corresponding user IDs supplied by your business platform.
| Available information | What to establish |
|---|---|
| Retained palm images | Are the required RGB and IR images available and suitable for registration? |
| Business user IDs | Can each image set be reliably associated with the intended user? |
| Existing registration records | Can your platform distinguish Small Model records from new Large Model registrations? |
| Large Scale API documentation | Does your script follow the required input and response formats? |
Confirm these points before committing to a transition schedule.
2. The Small and Large Models Remain Separate
X-Telcom’s Small Model and Large Model are independent, decoupled systems.
Their identifiers serve different purposes:
- The Small Model uses
featureIdto identify a palm. - The Large Model uses
user_idto identify a user defined by your platform.
A Small Model feature ID does not automatically become a Large Model user ID.
When retained images are submitted to the Large Scale registration API, the Large Model creates its own registration associated with the supplied user ID.
Your business platform maintains the relationship between that user and the relevant customer or employee account.
3. Use the Business User ID Associated with the Images
Before submitting an image set, your script must know which user it belongs to.
In the Large Model, your platform generates and provides the user ID. The SDK and Algorithm Server do not generate it for you.
For example, your platform may associate a retained image set with:
customer-123
That identifier must refer to the intended business record consistently throughout registration and subsequent identification.
Follow the ID requirements
The documented user ID requirements are:
- Between 1 and 128 bytes.
- Case-sensitive.
- No control characters, including tabs and newlines.
- No backslashes.
Letters, digits, hyphens and underscores are recommended.
Do not assume that image filenames or existing feature IDs provide a reliable business account association. Validate that relationship in your platform.
4. Register Users Through Individual API Calls
The documented approach is for the customer’s development team to create a script that calls the Large Scale registration API one user at a time.
For each user, the script supplies the required palm images and corresponding user ID in the documented request format.
There is no confirmed separate bulk-migration endpoint in the supplied technical guidance. Do not design the process around an assumed database import or bulk-upload interface.
Recommended script responsibilities
Beyond constructing valid requests, a practical registration script should:
- Read the user’s ID and corresponding image records.
- Check that the required inputs are available.
- Submit the registration request.
- Interpret the documented response.
- Record the outcome for review.
These are implementation recommendations for your development team, rather than a description of an existing X-Telcom migration utility.
Use the API documentation to determine supported request behaviour, including how to handle an identifier that may already exist. Do not assume duplicate submissions are automatically safe.
5. Test a Representative Sample Before Processing Everyone
Start with a limited set of records before running the script across the full user population.
The purpose is to validate the complete process:
- Images can be read correctly.
- Each image set belongs to the supplied user ID.
- Request inputs meet the API requirements.
- Registration responses are handled correctly.
- The resulting identification resolves to the intended business account.
Include records representative of the data your project has retained.
A successful registration response is an important checkpoint. It should be followed by identification testing to confirm that the resulting application workflow behaves as intended.
6. Can Users Avoid Another Palm Scan?
Retained images can remove the need to capture the palm again when those images are suitable for Large Model registration and correctly associated with the user.
That does not justify promising that every existing record will register successfully.
| Data situation | Practical implication |
|---|---|
| Suitable required images and reliable user mapping are available | Test registration using the retained data |
| Required images are missing | New palm capture may be necessary |
| Image-to-user association is uncertain | Resolve the association before registration |
| Registration fails | Investigate the documented response and decide whether data correction or new capture is required |
For palm vein payment projects, correct account association is particularly important. A technically valid image must still belong to the account represented by the supplied user ID.
7. Handle Image Encryption According to the Target Interface
If your project uses optional image encryption, the registration script must follow the Large Model’s image-encryption requirements.
The confirmed image-encryption method is AES-256-GCM. When uploading an encrypted image, set:
is_image_encrypted: true
The uploaded payload must match the server’s decryption format.
Setting the metadata flag does not encrypt the file. Likewise, an encrypted feature string is not a substitute for the required image input.
Customers generate, configure and manage their image-encryption keys. X-Telcom does not provide or retain them.
Confirm the required payload format before processing encrypted image records at scale.
8. Track Outcomes So Incomplete Records Are Visible
A registration process should make it easy to distinguish completed records from records requiring attention.
Useful outcome categories for your own tracking include:
- Successfully registered.
- Missing required input.
- Uncertain user association.
- Registration unsuccessful.
- Pending technical review.
These are suggested project-tracking categories, not API status codes.
Record the actual service responses separately and interpret them according to the documentation. This helps your team investigate failures without treating every unsuccessful request as the same problem.
Avoid including encryption keys in troubleshooting records.
9. Validate the Application Before Retiring the Previous Workflow
Creating Large Model registrations is one part of the project. Your application must also use the relevant SDK, service configuration and identifier handling.
The Small Model and Large Model SDKs should not be used together in the same application build.
Before retiring a previous workflow, establish acceptance criteria for:
- Registration completeness.
- Correct user-account associations.
- Identification on the intended terminal application.
- Payment or other business actions following identification.
- Handling of records that still require attention.
Retirement and deletion of the previous environment should follow your project’s agreed data-retention and operational procedures. Successful registration in the Large Model does not automatically delete data from the Small Model.
Frequently Asked Questions
Can we copy the Small Model database directly into the Large Model?
The documented approach is to use retained palm images and corresponding user IDs to call the Large Scale registration API for each user. It is not a direct database merge.
Can we register users using featureId alone?
Not through the documented image-based process. Suitable palm images and the corresponding business user ID are required.
Does every user need to scan again?
Not necessarily. Suitable retained images may be used for registration. Missing or unsuitable images can make new palm capture necessary.
Does X-Telcom provide a confirmed bulk-import endpoint?
The supplied technical guidance documents individual registration API calls through a customer-developed script. A separate bulk-migration endpoint is not confirmed.
Will the same customer account remain usable?
Your business platform can maintain its existing customer record and associate it with the Large Model user ID. Your team must validate that relationship and the surrounding application workflow.
Can we test before purchasing the large-model algorithm?
Yes. X-Telcom provides a Large Scale SDK Demo and public-cloud testing environment before algorithm purchase. Use this evaluation to validate registration and identification before planning production deployment.
Plan Your Large Model Registration with X-Telcom
Begin with a data-readiness check: required images, reliable user associations and a tested registration process.
Then validate a representative sample before processing the wider user population.
Contact X-Telcom to discuss your retained palm data, compatible terminals and Large Scale SDK evaluation requirements.
