For KYC, Singpass Login is not enough: the verified data comes from Myinfo.

Myinfo is the data service that sits behind it. With the individual's consent, it releases government-held details such as name, NRIC or FIN number, nationality, date of birth and registered address to the service they are using.

Two different products

Teams often say "Singpass" when they mean two separate products. Singpass Login is an OpenID Connect authentication service. It tells you that the person holding the phone passed Singpass authentication and gives you an identifier.

Myinfo is a data retrieval service. It returns the person's government-held attributes after they consent on a Myinfo screen.

The UUID is the way to recognise a returning person without holding their NRIC, so a login-only use case should normally take the UUID. KYC is different: a bank needs the NRIC or FIN, and gets it from Myinfo with consent.

Use the current Singpass developer specifications for authentication, security and migration requirements. Confirm the supported API version and deadlines before starting a build; do not base a new integration on a legacy specification.

What Myinfo can return

The Myinfo data catalogue lists each attribute with the agency that supplies it and whether it is available for citizens (SC), permanent residents (PR) or FIN holders. The identity attributes come from the Immigration and Checkpoints Authority (ICA) and, for FIN holders, the Ministry of Manpower (MOM).

The table shows the attributes most onboarding teams use. Attribute IDs are as they appear in the catalogue.

Three details matter for data mapping:

• Codes: the catalogue's Start Here page says Myinfo country and nationality codes do not strictly conform to ISO 3166-1 alpha-2, so a lookup table built from the Myinfo code listing is needed.
• Residential status: the field is blank for FIN holders, so a workflow that branches on citizenship must handle an empty value.
• Date of birth: it is not always a full date and can arrive as a year and month or a year only.

Our GovVerify Singpass service returns the attributes available for the approved use case and the individual’s requested consent set. Availability varies by residency, source agency and scope; do not assume every catalogue attribute is included.

The consent screen

A Myinfo retrieval starts with an authorisation request to the Singpass authorisation endpoint. The person authenticates with Singpass, then sees a consent page listing the data items your application has asked for.

They approve, and Singpass returns an authorisation code to your redirect URL. Your server exchanges it for a token, and the person data for the approved scopes follows from the userinfo endpoint.

The person consents to all the data items in the request together. The Myinfo FAQ says the consent page cannot be customised to let them pick items, and that someone who does not want to share can fill the form manually instead.

Three rules in the Myinfo documentation shape what you build around that screen:

• Request only the scopes you need: the Key Principles page says not to over-collect, and each request is reviewed before approval.
• Display everything you retrieve: the FAQ says all data retrieved from Myinfo has to be displayed on the form for the person to check before they submit it, and government-sourced fields should not be editable.
• Offer an alternative: the onboarding pre-requisites say Singpass cannot be the only form-filling or authentication option.

Becoming a relying party

Access runs through the Singpass Developer Portal, with staging for mock data and production for approved live use. The approval path includes:

1. Meet the pre-requisites: your organisation must be a Singapore-registered entity, government or private sector, and a regulated firm supplies its licence. Each data scope must be justified by the use case, and the service must offer a non-Singpass option.
2. Get access to the portal: your Corppass administrator grants your Singpass account permission for the Singpass Developer Portal.
3. Create a staging app: choose the app type (Singpass Login, Singpass Myinfo, Myinfo Business or Sign with Singpass), enter the app and technical details, select scopes and submit. Test against staging with the published Myinfo test personas.
4. Switch to production: toggle the dashboard to production and consent to the Singpass Service Agreement, which applies to private-sector partners without an existing agreement, and fill in the agreement contact details.
5. Create a production app: use the same details and scopes, upload the completed User Journey template for your use case (Myinfo or Login), tick the acknowledgement and submit. The submission is routed for approval.

What MAS expects

MAS Notice 626 is the Monetary Authority of Singapore's anti-money laundering and countering the financing of terrorism notice for banks, last revised on 30 June 2025.

Paragraphs 6.5 and 6.6 require a bank to identify each customer and, for a natural person, obtain at least the full name, unique identification number, residential address, date of birth and nationality. Paragraph 6.9 requires the bank to verify the customer's identity using reliable, independent source data, documents or information.

Paragraphs 6.27 to 6.29 require policies and procedures for the risks of non-face-to-face business relations. Where there is no face-to-face contact, CDD measures must be at least as robust as those with face-to-face contact. Other MAS notices carry the same structure for other sectors; our Singapore KYC and AML page lists them.

MAS has addressed Myinfo directly. Circular AMLD 01/2018 of 8 January 2018, on the use of MyInfo and CDD measures for non-face-to-face business relations, says MAS considers MyInfo a reliable and independent source for verifying the customer's name, unique identification number, date of birth, nationality and residential address.

Where MyInfo is used, MAS will not require a financial institution to obtain additional identification documents to verify the customer's identity, and will not expect it to separately obtain a photograph of the customer.

The institution must still keep records of the data, including data obtained from MyInfo. Customers who are not on MyInfo or do not consent go through the ordinary CDD requirements.

A Myinfo retrieval, with the consent record and the data displayed to the customer, is therefore accepted as identity verification for a Singapore resident. The bank still owns the rest of customer due diligence: screening, risk rating, beneficial ownership and ongoing monitoring.

Where integrations go wrong

• Treating Singpass Login as verification: Login proves the person authenticated; it does not return verified particulars. KYC needs Myinfo.
• Forgetting the consent record: the audit trail should show what was requested, what the person approved and when.

How Fill Easy fits in

A Hong Kong firm can discuss access through our Singpass and Myinfo connection. The arrangement must cover the relying party, your use case, the recipient and the requested data scopes; an intermediary does not remove approval requirements.

We hold the Singpass and Myinfo connection and expose it through GovVerify. Your system starts a verification through the API, the customer approves inside Singpass, and the result returns in the same schema as an iAM Smart check in Hong Kong, with the source and retrieval time recorded.

Chocolate Finance moved its Singpass verification to Fill Easy so that Singpass and iAM Smart run through one API and one team; see the case study. The API reference is at docs.fill-easy.com (opens in a new tab), and the identity schemes are listed in the catalogue.

What share of your Singapore customers come through Myinfo today?