Government services
Application connections to ESIA, SMEV, GIS GMP and GIS Housing — subject to scope, participant authority and operator documentation.
Review the connection scopeExplore the scopeFirst, verify the organisation’s authority to receive and send the required information.
Identity and sign-in. Verify scenario eligibility, system registration and available information.
Connection for an agreed identification and authentication scenario. Check applicability, information-system registration, available data and current connection conditions.
Requests, responses and statuses for specific information types and granted permissions.
Work with specific information types and granted permissions. Design requests, response processing, statuses and errors according to the chosen exchange documentation.
Charges and payments within participant authority. Identifiers, statuses and reconciliation rules.
Exchange information on government and municipal payments within the authority of the relevant participant. Agree charge identifiers, statuses and reconciliation rules.
Sector data for eligible organisational functions. Current formats, reference data and acceptance validation.
Connect an information system to GIS Housing for the applicable functions of the organisation. Use current procedures and formats, and validate reference data and acceptance results.
The external system has its own connection procedures. We plan the implementation around them so the product does not depend on an unavailable scenario.
For SMEV, document the specific exchange, documentation and allowed operations. Access to one information type does not imply access to others.
Determine certificates, signing tools and accounts from the chosen connection documentation and client infrastructure.
Check current and transitional formats before development and launch. Agree the upgrade plan with the system owner.
These inputs help estimate the application work and identify organisational and infrastructure dependencies.
| Source / scope | What we define | Outcome |
|---|---|---|
| Organisation and role | Client, system owner and participant authority | Applicable connections |
| Scenario | Information requested or submitted | Agreed operation scope |
| Documentation | Procedure, schema and format version | Technical exchange contract |
| Infrastructure | Environments, access, certificates and owners | Test and switch-over plan |
The user interface and external connection procedure are separate workstreams. Every stage has an outcome and an owner.
Together with the client, define authority, permitted data, procedures and required approvals. Check test-environment availability.
Map internal records to external identifiers and reference data. Define successful acceptance and how rejections are handled.
Build the exchange module. Validate access, signing where needed, invalid data, duplicate messages and pending responses.
Switch after agreed checks and external procedures are completed. Provide instructions, exchange logs and support arrangements.
Applicability and access depend on the system, organisation status and scenario. We check current operator documentation before committing to scope and timing.
No. Information and operations are limited by granted rights and the specific exchange. We design within those boundaries.
Roles are documented in the connection plan. The client confirms authority and performs required organisational actions; we prepare the agreed technical work.
Separate development time from external dependencies. Refine the estimate after reviewing procedures, environment availability and source data.
Tell us the organisation, government system and required information. Indicate whether participant registration, access and a test environment are available.
Review the connection scope
