Singpass and Myinfo: evidence for an onboarding decision
Myinfo can provide consented government-held particulars. The onboarding workflow needs to preserve their source, handle missing fields and complete the remaining due diligence.
By Matthew Lee
A person can authenticate with Singpass without supplying every identity attribute an onboarding team needs. Singpass Login and Myinfo serve different purposes: Login authenticates the user, while Myinfo supplies approved government-held attributes after the individual consents. Planning the journey around that distinction helps the team collect the evidence required for its service.
Relevant rules and service conditions
MAS Notice 626 governs banks’ AML/CFT requirements, including identification, verification and non-face-to-face risks. Other regulated sectors have their own applicable notices. MAS has addressed the use of Myinfo as a reliable, independent source for specified identity particulars, while the firm remains responsible for the rest of customer due diligence.
The applicable regulatory requirements sit alongside Singpass’s relying-party, security, use-case and data-scope conditions. Confirm the current developer specifications and approvals for the actual integration. A third-party connection still needs an arrangement covering the relying party, recipients and requested use.
Evidence to plan for
| Evidence | What the team needs to establish |
|---|---|
| Approved Myinfo attributes | Which identity particulars are available for the person and use case |
| Consent and transaction record | What data was requested and authorised for release |
| Source and retrieval record | Where the particulars came from and when they were obtained |
| Alternative verification evidence | How people outside the supported journey can complete onboarding |
| Screening and relationship information | The remaining assessment beyond identity particulars |
| Authority evidence for a corporate representative | Whether the identified individual may act for the company |
The available attributes depend on the source agency, the individual’s status and the approved scopes. A corporate representative’s identity result should therefore be read alongside the company’s mandate or authorisation. Verifying who the person is does not explain the powers they hold.
Design around the data and consent
The person authenticates and approves the requested data through the government journey. Your system receives the result for the authorised scope and needs to preserve the associated evidence. Request the attributes the use case actually needs, and follow the provider’s requirements for displaying government-sourced data and offering an alternative route.
The data catalogue also matters when designing the form. Nationality codes may use the provider’s own code list, some attributes may be absent for particular populations, and a date may have less precision than a full calendar date. Handle those cases explicitly so the application does not invent missing data or reject a legitimate user through an incorrect assumption.
Risks to resolve
Authentication and data evidence can be confused. A successful Login transaction does not automatically give the team a complete set of verified identity particulars. Define which attributes the onboarding decision needs, then check that the approved Myinfo result actually contains them.
Partial results can be hidden by form defaults. Replacing a missing address or incomplete date with a guessed value creates information the source never supplied. The workflow should preserve the original precision and identify what further evidence is needed under the firm’s policy.
Consent can become detached from the result. A retained identity record needs to be connected to the relevant request and authorised purpose. Clear transaction references and retention procedures help the reviewer understand how the data was obtained and used.
Identity is one part of due diligence. The team still needs the relationship’s purpose, relevant screening and, for a corporate customer, ownership and authority evidence. The result supports that work within its verified scope.
How Fill Easy helps
GovVerify provides Fill Easy’s Singpass and Myinfo connection through the API channel, subject to the approved arrangement and consented attributes. Source and retrieval information accompany the identity result. Discuss the relying party, recipients and scope before choosing the journey.
The email bot serves a related company-evidence task. An approved organisational sender can ask agent@fill-easy.com for the corporate customer’s available ACRA records, with its legal name, UEN, requested documents and case reference. The bot clarifies the request and returns retrieved PDFs in the same thread, with source, retrieval time and request ID; availability, price and turnaround are confirmed at acceptance.
That combines individual identity evidence with company records through their appropriate channels. The Singapore onboarding guide explains the corporate documents commonly used alongside the representative’s identity and mandate.