Designing a welfare information system for Thai government data exchange

A welfare information system is the system an agency uses to keep a register of beneficiaries, check eligibility against the rules, track payment status and record the evidence behind each officer's decision. Designing one to connect with Thai government data does not start with data volume. It starts with three things: using the 13-digit citizen ID to match records but not as the primary key, requesting data from the agency that owns it instead of collecting it again, and having a legal basis and an audit trail for every exchange.

This guide is for IT teams in Thai government agencies and local administrative organisations, committees drafting the terms of reference (TOR), and developers designing or improving a welfare system such as an old-age allowance system. It covers the data design, the government data-exchange channels that actually exist, and the legal duties that shape the design. Procurement and TOR writing are covered in our guide to Thai government IT procurement. Laws and agency pages cited were checked on 3 November 2026; links are in the sources at the end.

What data structure should a welfare information system have?

Split the data by function instead of putting everything in one beneficiary table. Each part changes for different reasons, has a different owner and needs a different kind of audit. The structure we recommend:

Should the 13-digit citizen ID be the primary key?

We recommend against it. The citizen ID is needed to match records with other agencies, but as a primary key it spreads into every table, every foreign key and every export, and often leaks into URLs and logs. A lower-risk approach:

• Use a system-generated surrogate key as the primary key and for references between tables.
• Keep the citizen ID in a single identity table, encrypted in the database, and look it up by a keyed hash rather than the plain value.
• Show it masked on screen, reveal the full number only to roles that need it, and log every reveal.
• Keep it out of URLs, error messages, application logs and test data; use masked data in test environments.

How should eligibility rules that change with regulations be stored?

As versioned data with effective dates, not as if-else conditions in code that are edited over and over. When a regulation changes, the new rule set applies to applications from its effective date, while earlier decisions must still be explainable under the rule set that applied then. Each decision should store three things together: the rule version, the input data with its source and retrieval time, and the approver. When someone asks why a person did or did not qualify, officers can answer from the system.

How do you sync payment status from another system without duplicates or gaps?

Make processing of returned results idempotent, using a key that is unique per beneficiary per payment round. Record status as appended events, such as prepared, sent, confirmed or failed with a reason, rather than overwriting one status field, and reconcile item counts and totals against each return. Items with no result within the agreed time should appear as outstanding, not quietly disappear.

Which agencies does a local allowance system exchange data with?

As far as the Department of Local Administration (DLA) shows on its websites, the system waits for check results returned by the Comptroller General's Department, and the citizen-facing service supports login with ThaID (details below). The full list of integrations is not published, but this is enough to show a system whose data crosses agency boundaries from the start.

The structure comes from the preamble of the Ministry of Interior regulation on living-allowance payments by local administrative organisations of 2005 (B.E. 2548). It states that the allowance mission for older persons, people with disabilities and people with AIDS was transferred to the Ministry of Interior under the 1999 Act on decentralisation to local administrative organisations, and the Ministry issued the regulation so that local organisations with sufficient finances can pay the allowance; local organisations therefore pay it in their areas. We cite that regulation only to explain this structure. Current eligibility rules and payment rates follow the regulation now in force, so this article does not state rules or amounts; check the Royal Gazette and DLA's instructions.

At the system level, DLA runs a living-allowance database system for local administrative organisations (in Thai), which requires a login; its home page notes that check results become available only after data is returned from the Comptroller General's Department. For citizens, DLA offers the old-age allowance service in the Digital DLA app, which supports login with ThaID, and Thai applicants must enter their citizen ID.

Together these tell a connecting system what it must handle: some results come back from another agency later, so it needs pending states and reconciliation; and applicants can be identified through a digital identity service, so the agency system should accept verified data from that channel rather than have officers retype it.

Does a welfare system really need big data?

For most welfare systems, the problem is not data volume large enough to need big-data technology. It is combining records from several registers with different owners so that they are accurate and current. The law makes the same point: section 8 (3) of the Digital Government Act of 2019 (the Act on Government Administration and Services through Digital Systems B.E. 2562) requires government data governance to include measures that keep data accurate, complete, available, current, integrated and exchangeable.

A clear example is TPMAP (Thai People Map and Analytics Platform), developed by the Office of the National Economic and Social Development Council (NESDC) with the National Electronics and Computer Technology Center (NECTEC). It works by comparing two datasets: the Community Development Department's basic minimum needs survey data and the Ministry of Finance's state-welfare registration data. People who appear in both are the target poor; since 2023 the definition also includes poor people not registered for the welfare card. The core work in such a system is record linkage between registers and deciding which source to trust when they disagree.

In engineering terms, budget and time should go to data-quality checks, identity matching and tracking how fresh each source is, before investing in a large-scale data-processing platform. A well-designed relational database can hold a provincial or national beneficiary register; policy analysis can run separately on a de-identified copy.

What does Thailand's Digital Government Act say about connecting government databases?

The Digital Government Act of 2019 (Royal Gazette vol. 136, part 67 Kor, 22 May 2019) sets several data duties for state agencies. Those that shape a welfare system directly:

• Section 8: government data governance must at least cover rights, duties and responsibilities for managing data; a system for managing and protecting data from creation to destruction; data-quality measures; access policies and protection of personal data; and descriptions (metadata) of government datasets.
• Section 12: agencies must keep mission data in digital form that is accurate, current and exchangeable, provide digital identity proofing and authentication, and have security systems that at least prevent or respond to cyber threats under the cybersecurity law. Its final paragraph says that where another agency is responsible for that data as master data, the agencies should link and exchange it rather than recreate all of it.
• Sections 13 and 14: an agency must link and exchange the digital data it holds when another agency requests it, and the receiving agency may use the data only for purposes within its own duties and powers, must keep it secure, and must not disclose or transfer it to anyone without a right of access.
• Section 15: establishes a central data-exchange centre for digital data and digital registers between state agencies; its duties include proposing linkage policy and standards for the Digital Government Development Committee's approval and keeping evidence records of linkage and exchange.
• Section 16: subject to personal-data protection law, an agency that needs digital personal data for public administration may request linkage and exchange from the agency that holds it, to analyse or process it.
• Section 19: initially, the Digital Government Development Agency (DGA) was to run the exchange centre temporarily for no more than two years, after which the Digital Government Development Committee would decide which agency continues it.

The final paragraph of section 12 translates directly into design: data another agency owns, such as civil registration data, should not be kept and edited as a second copy in the welfare system. Store only what a decision needs, with its source and retrieval time, and fetch it again when needed. Section 14 means data obtained to assess one benefit should not automatically be reused for other work, so the data-sharing register must tie each dataset to the purpose it was requested for.

For standards, DGA publishes digital government standard No. 5 of 2022 on data-quality assessment for government agencies (in Thai), which assesses five dimensions: accuracy and completeness, consistency, meeting user needs, timeliness, and availability. These five make good headings for a data-quality report the system should produce on its own.

Which channels exist for connecting to government data?

What is GDX, and who can connect?

According to DGA's service page, GDX is a platform for sending and receiving data, documents and digital registers between state agencies. Data-owner agencies continue to store and manage their own data, and the transferred data is not stored in GDX.

The same page says the service is not available to the general public or private-sector organisations. Agencies are data controllers and DGA is a data processor; an agency can establish a data processing agreement (DPA) with DGA, and DGA provides API documentation, connection tests and usage statistics. In a real project, the agency applies for the service and the contractor builds the agency-side system that calls the API under the agency's agreement. Available datasets are listed in the GDX data catalogue. The usage statistics on the service page are dated March 2022, so we do not repeat them as current figures; ask DGA for the current position.

What is the Department of Provincial Administration's Linkage Center?

The Linkage Center is the central population-database linkage system that the Department of Provincial Administration was assigned to run under a Cabinet resolution of 2 October 2018 on not requiring citizens to submit copies of government-issued documents. Access to civil registration data requires the department's approval under its own rules. Confirm the steps and conditions with the department directly; we do not describe them because we have not checked a current official document.

How are these channels changing?

On 15 September 2026 the government announced (in Thai) a push to stop requiring copies of 58 documents through GDX within one year of the Cabinet resolution: 31 documents whose data is already available through GDX must be used by agencies instead of paper within six months to a year, and the other 27 are to be linked within a year. It also asked the Department of Provincial Administration to accelerate linking GDX with the Linkage Center so agencies can reach civil registration data through a single channel. At the time of writing, that last item is an announced plan, not completed work.

The design consequence: do not tie welfare logic to any one channel. Use an integration layer that separates each source's adapter from the eligibility logic, so when a channel changes the work stays in the adapter rather than across the system.

PDPA for government agencies: what legal basis does a welfare system use?

Which legal basis covers general personal data without consent?

Section 24 of the Personal Data Protection Act of 2019 (PDPA) allows collection without consent in certain cases. The closest to state welfare work are (4), where it is necessary to perform a task in the public interest or exercise state authority vested in the controller, and (6), where it is to comply with law. Paragraph (5) is legitimate interest, which is not the main basis for a state mission. Record the basis for each activity in the data-sharing register and the record of processing activities.

Does disability and health data need consent?

Section 26 treats health, disability and biometric data (which includes facial images, iris and fingerprints) as sensitive data that needs explicit consent unless an exception applies. The exception that fits welfare systems such as a disability allowance is (5) (c): where it is necessary to comply with law for labour protection, social security, national health insurance, legally entitled medical welfare, road-accident victim protection or social protection, with appropriate measures to protect the data subject's fundamental rights and interests. In system terms, that means separating sensitive data from general data, limiting who can see it and logging access to it more strictly.

What role does the contractor running the system have under the PDPA?

Section 40 requires a data processor to act only on the controller's instructions, to have security measures and notify the controller of breaches, and to keep a record of processing activities. A processor that does not follow instructions is treated as the controller for that activity, and the controller must put an agreement in place between them. What that agreement should cover and how to write it into a TOR is in our government IT procurement guide.

Does the agency need a data protection officer?

Section 41 requires a data protection officer (DPO) where (1) the controller is a state agency named by the Committee, (2) its activities require regular monitoring because of the large amount of data, as the Committee prescribes, or (3) its core activity is processing sensitive data under section 26. For (1), the Committee's 2023 notification on state agencies required to appoint a DPO (in Thai) names agencies individually, such as the Comptroller General's Department, the Department of Provincial Administration, the Community Development Department and the Department of Empowerment of Persons with Disabilities, and its second notification of 2025 adds only provinces, provincial administrative organisations, city municipalities and Pattaya City. Town and subdistrict municipalities and subdistrict administrative organisations are not on either list, but conditions (2) and (3) of section 41 still depend on each organisation's processing; that is for its legal adviser to decide.

What minimum security measures does citizens' data need?

PDPA section 37 requires controllers to have appropriate security measures meeting the Committee's minimum standard, to prevent recipients from misusing or disclosing data, to have a system for erasing or destroying data after its retention period, and to notify the Office of the Personal Data Protection Committee of a breach without delay and, where feasible, within 72 hours of becoming aware of it, unless the breach poses no risk to people's rights and freedoms. Where the risk is high, data subjects must also be told, with remedies, without delay.

That minimum standard is the Committee's 2022 notification on security measures for data controllers (in Thai). It requires appropriate organisational and technical measures, which may include necessary physical measures, matched to risk, covering paper and electronic data, and a defence-in-depth approach, and at minimum the four items below. The table shows what each becomes in a welfare system.

Clause 6 of the same notification has the controller consider requiring, in the processor agreement, measures meeting the minimum standard and breach notification to the controller. Section 12 (5) of the Digital Government Act also requires agencies to have security systems that at least prevent or respond to cyber threats under the cybersecurity law; an agency's specific duties under that law depend on its status, which this article does not analyse.

Two things welfare systems often miss: retention and destruction under section 37 (3), which should be set per data type with the system able to delete or mask data automatically when the period ends; and a breach procedure that can really meet 72 hours, which depends on finding out quickly which records leaked and whose. A well-designed audit log is what makes that question answerable.

The three main challenges in connecting digital welfare systems

Given the requirements above, the difficulty of connecting a welfare system to government data comes mainly from the data, not from the technology that moves it.

1. Matching the right person across registers: each register holds a person's name, address and status as of a different time, and name changes, moves and deaths reach each system at different times. Even matching on the citizen ID, you must decide which source is master for which field, following the final paragraph of section 12; provide a queue for officers to review unmatched or conflicting records; and never let the system remove an entitlement automatically on unconfirmed data.
2. A separate legal basis and agreement for each data owner: each source has its own owner, access rules and agreement, under sections 13 and 16 of the Digital Government Act and section 24 or 26 of the PDPA, and data obtained may be used only for the purpose requested under section 14. This work moves at the data owner's pace, not the development team's, so access requests must start early in the project, and the system needs a data-sharing register that shows which agreement each field came from.
3. Quality, freshness and evidence across agencies: upstream data can be late or incomplete, and some results come back from another agency later. The system must know when each field was obtained, check quality against the five dimensions of DGA's data-quality standard, show items awaiting results or failing reconciliation, and keep evidence of what data each decision used, so it can answer auditors and citizens who complain.

Procurement and project-management reasons that government IT projects stall, such as unclear specifications or no budget for care after delivery, are covered separately in why government IT projects fail in Thailand. Controlling scope and budget during the project, including payment periods that each deliver working software under a fixed-price contract, is covered in keeping a software project on budget.

What should an agency prepare before drafting a TOR for a welfare system?

Enough facts about the data for bidders to estimate the integration work, because integration is easy to underestimate.

• The external data sources needed, their owners, the channel (such as GDX or the owner's own channel) and the status of each access request.
• A data-flow diagram from application through eligibility check and payment to returned results.
• The types of personal and sensitive data the system will hold, with the legal basis agreed by the legal adviser or DPO.
• User roles and the data scope of each.
• Requirements for the audit log, retention and destruction.
• For an existing system: data to migrate, its current quality and who maintains it now. If the existing system will be maintained under contract, see what a legacy-maintenance TOR should specify.

Procurement methods, public hearing of the draft TOR, data processing agreements and maintenance budgets are in our government IT procurement guide; more articles are in IT systems for government agencies.

Frequently asked questions

Can a private company or contractor connect to GDX directly?

No. DGA's English GDX page says the service is not available to the general public or private-sector organisations. The state agency applies as data controller, DGA acts as processor and can sign a DPA with the agency, and the contractor builds the agency-side system under the agency's agreement.

Does an agency need citizens' consent to use their data in a welfare system?

Not necessarily. PDPA section 24 (4) covers processing necessary for a public-interest task or the exercise of state authority, and section 24 (6) covers compliance with law. For sensitive data such as disability or health, section 26 (5) (c) covers processing necessary to comply with law for social protection, with appropriate safeguards. The basis for a real system should be confirmed by the agency's legal adviser or DPO.

Must a subdistrict administrative organisation appoint a DPO?

It is not on the lists in the Committee's 2023 notification or the 2025 second notification, which adds only provinces, provincial administrative organisations, city municipalities and Pattaya City. Section 41 (2) and (3) can still apply depending on the organisation's processing, so ask a legal adviser.

Should the citizen ID be the database's primary key?

We recommend against it. Use an internal surrogate key, keep the citizen ID in one encrypted identity table searched by a keyed hash, mask it on screen and keep it out of URLs, logs and unnecessary exports.

Assess the system design and data integration

If an agency is planning a new welfare system, or an existing one shows duplicate records, data that disagrees with its sources, or no clear answer to who accessed what, assessing the data structure, integration points and access controls before drafting a TOR or changing the system produces a list of what to fix and the facts needed to write the scope.

UNIXDEV builds systems for government agencies, including internal systems, citizen-facing services, APIs and system integration, under a software process certified to ISO/IEC 29110-4-1:2018, and connects legacy systems to new ones through API design, ETL and data sync. We are registered as a vendor in e-GP and certified to ISO 9001:2015 and ISO/IEC 27001:2022. Connecting to GDX or another agency's data is the agency's right; the contractor's job is to build the agency-side system under the agreement the agency holds.

If an agency wants the same firm to assess the system and later bid on the same project, it should first ask its procurement unit whether any restriction applies.

Send what you have, such as the benefit types, the sources to connect and the current system, through the project brief form. Do not send citizens' personal data at this stage.

Sources and further reading

• Digital Government Act B.E. 2562 (2019) (the Act on Government Administration and Services through Digital Systems B.E. 2562): Royal Gazette vol. 136, part 67 Kor, 22 May 2019 (sections 8, 12, 13, 14, 15, 16, 19), copy published by the Department of Special Investigation, in Thai
• Personal Data Protection Act B.E. 2562 (2019): Royal Gazette vol. 136, part 69 Kor, 27 May 2019 (sections 24, 26, 37, 40, 41), in Thai · copy published by the Ministry of Digital Economy and Society
• PDPC notification on security measures for data controllers B.E. 2565 (2022): Royal Gazette vol. 139, special part 140 Ngor, 20 June 2022, in Thai
• PDPC notification on state agencies required to appoint a DPO B.E. 2566 (2023): Royal Gazette vol. 140, special part 174 Ngor, 18 July 2023 · No. 2, B.E. 2568 (2025): Royal Gazette vol. 142, special part 329 Ngor, 9 October 2025, in Thai
• DGA digital government standard No. 5 (2022) on data-quality assessment: supporting document published by DGA, in Thai
• DGA: GDX service · Thai page · GDX data catalogue
• Royal Thai Government: news of 15 September 2026 on not requiring copies of 58 documents through GDX, in Thai
• Bureau of Registration Administration, Department of Provincial Administration: The One journal, October 2018 (Cabinet resolution of 2 October 2018 and the Linkage Center), in Thai
• Ministry of Interior regulation on living-allowance payments by local administrative organisations B.E. 2548 (2005): Royal Gazette vol. 122, special part 109 Ngor, 30 September 2005, cited only for the transfer of the mission, not current rules, in Thai
• DLA: living-allowance database system for local administrative organisations · old-age allowance service on Digital DLA, in Thai
• TPMAP: about, in Thai
• Related: Thai government IT procurement, e-GP, the TOR and maintenance budgets
• Related: why government IT projects fail
• Related: Writing a TOR for legacy system maintenance
• Related: keeping an end-of-support legacy system running safely
• Related: keeping a software project on budget
• All articles on IT systems for government agencies

By the UNIXDEV Team · 3 November 2026 · A design summary, not legal advice. Legal texts checked against government-published copies as of the date of writing.