# https://idataraya.com > Every indexable page on this site, concatenated as markdown, in sitemap order. > Generated at build time from the same HTML the site serves. Each page is also available on its own at .md, or by sending Accept: text/markdown to the page URL. --- --- title: "The systems organisations run their work on | idataraya" description: "idataraya designs, builds, deploys, and maintains the systems organisations run their work on, and stays accountable for them in production." url: "https://idataraya.com/" --- ## Autonomous Engineering Teams that own a system outright, from the first architecture session through daily operation. No handover, no second vendor. We design, build, deploy, and maintain the systems organisations run their work on. One engineering team, accountable from the first architecture session through daily operation. [Operations Taking over a system you did not build: the first ninety days](https://idataraya.com/insights/inheriting-a-system/) [Payments Settlement files: the unglamorous half of payment acceptance](https://idataraya.com/insights/settlement-files/) [Public sector What tender documents get wrong about maintenance](https://idataraya.com/insights/tendering-for-maintenance/) [Data and AI The warehouse is rarely the problem: where reporting actually breaks](https://idataraya.com/insights/where-reporting-breaks/) [Integration What breaks in a bank integration, and roughly when](https://idataraya.com/insights/what-breaks-in-bank-integrations/) [Hardware Provisioning a terminal fleet without putting people in the field](https://idataraya.com/insights/provisioning-a-terminal-fleet/) [Perspective We build, and we maintain: inside the idataraya engagement model](https://idataraya.com/insights/the-engagement-model/) [Platform The asasii suite: production engines we compose every system from](https://idataraya.com/insights/the-asasii-suite/) ## One team, from architecture to operations Most systems are handed at go-live to a support desk that never saw them built. Yours will not be. The engineers who designed and built it are the ones who run it, so a fault is diagnosed by someone who already knows why the code works the way it does. [How we work](https://idataraya.com/about/) ## What are you trying to build or fix? Select a capability or an industry to see how we work in it: Capabilities [Payments and Acceptance](https://idataraya.com/capabilities/payments-and-acceptance/) [Payment Hardware](https://idataraya.com/capabilities/payment-hardware/) [Business Systems](https://idataraya.com/capabilities/business-systems/) [Payroll and HR Systems](https://idataraya.com/capabilities/payroll-and-hr/) [Artificial Intelligence](https://idataraya.com/capabilities/artificial-intelligence/) [Mobile Applications](https://idataraya.com/capabilities/mobile-applications/) [Digital and Technology](https://idataraya.com/capabilities/digital-and-technology/) [Data and Analytics](https://idataraya.com/capabilities/data-and-analytics/) [Cloud and Infrastructure](https://idataraya.com/capabilities/cloud-and-infrastructure/) [Security](https://idataraya.com/capabilities/security/) [Business Resilience](https://idataraya.com/capabilities/business-resilience/) [Operations](https://idataraya.com/capabilities/operations/) [Risk Management and Compliance](https://idataraya.com/capabilities/risk-management-and-compliance/) [The asasii suite](https://idataraya.com/asasii/) Industries [Financial Institutions](https://idataraya.com/industries/financial-institutions/) [Retail](https://idataraya.com/industries/retail/) [Public Sector](https://idataraya.com/industries/public-sector/) [Health Care](https://idataraya.com/industries/health-care/) [Education](https://idataraya.com/industries/education/) [Travel and Tourism](https://idataraya.com/industries/travel-tourism/) [Transportation and Logistics](https://idataraya.com/industries/transportation-logistics/) [Property Developers](https://idataraya.com/industries/property-developers/) [Malls and Commercial Property](https://idataraya.com/industries/commercial-property/) [Strata and Condominium](https://idataraya.com/industries/strata-management/) About idataraya ### Who we are and how we work [See how we work](https://idataraya.com/about/) The asasii suite ### Production engines we compose every system from [See the suite](https://idataraya.com/asasii/) Field notes ### What we have learned running the systems we build [Read the notes](https://idataraya.com/insights/) idataraya careers ## Stay with what you build Our engineers design a system, ship it, and then run it in production. You find out whether your architecture holds up under real load, and you are the one who fixes it when it does not. [Explore careers](https://idataraya.com/careers/) [Apply now](https://idataraya.com/careers/apply/) ![Two idataraya engineers reviewing an architecture diagram together at a desk in a Kuala Lumpur office](https://idataraya.com/landing-v2/careers.jpg) Field notes ## What we have learned running the systems we build, and what we would do differently next time Get new field notes when we publish them Subscribe --- --- title: "About idataraya | idataraya" description: "idataraya is a Malaysian software engineering company that builds and runs business systems, counter and payment software, integrations, and applied AI." url: "https://idataraya.com/about/" --- # About idataraya **idataraya bridges the gap between ambition and operation.** We are a Malaysian software engineering company. We build the systems organisations run their work on: CRM, billing and collections, vendor and supplier portals, counter and kiosk software, payment systems, and the core integrations, data platforms, and applied AI that connect them. What we design, we build. What we build, we run. Our Expertise ## Where AI Meets Autonomous Engineering We build for organisations where software needs to work reliably every day. Our focus is on systems that fit into existing operations, connect with the technology around them, and continue to evolve as the business changes. ### Industries - [Financial Institutions](https://idataraya.com/industries/financial-institutions/) - [Retail](https://idataraya.com/industries/retail/) - [Public Sector](https://idataraya.com/industries/public-sector/) - [Health Care](https://idataraya.com/industries/health-care/) - [Education](https://idataraya.com/industries/education/) - [Travel and Tourism](https://idataraya.com/industries/travel-tourism/) - [Transportation and Logistics](https://idataraya.com/industries/transportation-logistics/) - [Property Developers](https://idataraya.com/industries/property-developers/) - [Malls and Commercial Property](https://idataraya.com/industries/commercial-property/) - [Strata and Condominium](https://idataraya.com/industries/strata-management/) ### Capabilities - [Payments and Acceptance](https://idataraya.com/capabilities/payments-and-acceptance/) - [Payment Hardware](https://idataraya.com/capabilities/payment-hardware/) - [Business Systems](https://idataraya.com/capabilities/business-systems/) - [Payroll and HR Systems](https://idataraya.com/capabilities/payroll-and-hr/) - [Artificial Intelligence](https://idataraya.com/capabilities/artificial-intelligence/) - [Mobile Applications](https://idataraya.com/capabilities/mobile-applications/) - [Digital and Technology](https://idataraya.com/capabilities/digital-and-technology/) - [All 21 capabilities](https://idataraya.com/capabilities/) ## Transformative Impact in Action We work across the full lifecycle of a system. From understanding the business and defining the architecture to engineering, deployment, integration, and ongoing operation, our team stays responsible for the outcome. One team carries each system from the first architecture session through daily operation, so the people who designed it are the people running it years later. [Under a minutereporting that used to take a day MyPride, Jabatan Penjara MalaysiaMyPride moved from a manual workflow to one connected systemRead the study](https://idataraya.com/client-impact/mypride/) One portalapplication to live Client ImpactMerchant onboarding moved from courier bags to a single flow Semester closeon exceptions, not exports Client ImpactA university bursar office retired its spreadsheet marathon ## Technology We Work With Cloud ![Amazon Web Services](https://idataraya.com/logos/aws.svg) ![Google Cloud](https://idataraya.com/logos/google-cloud.png) ![Microsoft Azure](https://idataraya.com/logos/azure.svg) ![Alibaba Cloud](https://idataraya.com/logos/alibaba-cloud.png) ![DigitalOcean](https://idataraya.com/logos/digitalocean.svg) ![Cloudflare](https://idataraya.com/logos/cloudflare.svg) Platform ![Docker](https://idataraya.com/logos/docker.svg) ![Kubernetes](https://idataraya.com/logos/kubernetes.svg) Data ![PostgreSQL](https://idataraya.com/logos/postgresql.svg) ![MySQL](https://idataraya.com/logos/mysql.svg) ![MariaDB](https://idataraya.com/logos/mariadb.svg) ![Microsoft SQL Server](https://idataraya.com/logos/sqlserver.svg) ![Oracle](https://idataraya.com/logos/oracle.svg) ![MongoDB](https://idataraya.com/logos/mongodb.svg) ![Redis](https://idataraya.com/logos/redis.svg) ![SQLite](https://idataraya.com/logos/sqlite.svg) ![Elasticsearch](https://idataraya.com/logos/elasticsearch.svg) ![Apache Kafka](https://idataraya.com/logos/kafka.svg) ![Firebase](https://idataraya.com/logos/firebase.svg) Applied AI ![Claude](https://idataraya.com/logos/claude.svg) ![OpenAI](https://idataraya.com/logos/openai.svg) ![Ollama](https://idataraya.com/logos/ollama.svg) Languages ![TypeScript](https://idataraya.com/logos/typescript.svg) ![Go](https://idataraya.com/logos/golang.svg) ![Rust](https://idataraya.com/logos/rust.svg) ![Python](https://idataraya.com/logos/python.svg) Frameworks ![React](https://idataraya.com/logos/react.svg) ![Next.js](https://idataraya.com/logos/nextjs.svg) ![Vue.js](https://idataraya.com/logos/vue.svg) ![Angular](https://idataraya.com/logos/angular.svg) ![Node.js](https://idataraya.com/logos/nodejs.svg) ![Spring](https://idataraya.com/logos/spring.svg) ![Django](https://idataraya.com/logos/django.svg) Security ![OWASP](https://idataraya.com/logos/owasp.svg) ![Snyk](https://idataraya.com/logos/snyk.svg) ![Wazuh](https://idataraya.com/logos/wazuh.svg) ![Let's Encrypt](https://idataraya.com/logos/lets-encrypt.svg) Mobile ![Android](https://idataraya.com/logos/android.svg) ![iOS](https://idataraya.com/logos/apple.svg) ![Kotlin](https://idataraya.com/logos/kotlin.svg) ![Swift](https://idataraya.com/logos/swift.svg) ![React Native](https://idataraya.com/logos/react.svg) ![Flutter](https://idataraya.com/logos/flutter.svg) Desktop ![Electron](https://idataraya.com/logos/electron.svg) ![Windows](https://idataraya.com/logos/windows.svg) ![Linux](https://idataraya.com/logos/linux.svg) Engineering ![GitHub](https://idataraya.com/logos/github.svg) ![GitLab](https://idataraya.com/logos/gitlab.svg) ![Jira](https://idataraya.com/logos/jira.svg) ![Figma](https://idataraya.com/logos/figma.svg) Payments ![DuitNow](https://idataraya.com/logos/duitnow-qr.svg) ![FPX](https://idataraya.com/logos/fpx.jpg) ![MyDebit](https://idataraya.com/logos/mydebit.png) ![Visa](https://idataraya.com/logos/visa.svg) ![Mastercard](https://idataraya.com/logos/mastercard.svg) ![Touch 'n Go eWallet](https://idataraya.com/logos/touch-n-go-ewallet.svg) ![GrabPay](https://idataraya.com/logos/grab.svg) ![Stripe](https://idataraya.com/logos/stripe.svg) ## Explore More Next Section ### See the industries we serve and the capabilities we bring to them, from the payment counter to the back office. [Learn more](https://idataraya.com/industries/) [Section Capabilities](https://idataraya.com/capabilities/) [Section Featured Insights](https://idataraya.com/insights/) --- --- title: "The asasii suite | idataraya" description: "The 55 production modules idataraya composes its systems from, and the sectors each one runs in." url: "https://idataraya.com/asasii/" --- # The asasii suite asasii is not one product. It is 55 modules that have been through production, composed per client into the system that operation needs. A strata community and a logistics operator run almost nothing in common, and both run asasii. What is shared is the spine underneath: one identity for a customer, a parcel, or a parcel owner, one ledger, one catalogue where a catalogue applies, and every module reading those records rather than holding a copy of them. Removing the copies is what removes the reconciliation, and it is not something a client can retrofit later by buying more integration. ## Taking the money The counter, the screen, and the device behind them. One acceptance engine, whether the sale happens at a till, a kiosk, a checkout page, or a lane with nobody in it. ### POS ### Outlet POS ### Counter and Kiosk ### Campus Pay ### Checkout ### Payment Links ### Gateway ### Terminal Suite ### Unattended Terminals ### Fleet Management ### Merchant App ### Onboarding ### Developer Portal ## Selling and stock One catalogue and one stock position behind every channel, which is the only arrangement in which an online store cannot sell what the counter has already sold. ### Online Store ### BSC ### Inventory ### Purchasing ### Sales ### Reservations ### Pharmacy ## What is owed, and what arrived Billing that is produced from the agreement rather than typed beside it, and the arrears trail that turns a total into a case a committee can act on. ### Billing ### Progressive Billing ### Collections ### Arrears ### Utilities ### Settlement ### Bursar ### Group Reporting ### Claims ## One record per person, parcel, or unit The register everything else reads. Where the identity lives once, a correction is a correction everywhere rather than in three places and eventually. ### Register ### Student Records ### Admissions ### Registration ### Purchasers ### Leases ### Contracts ## The other party's own view Statements, balances, requests, and status, read from the same records the office works from. A portal that shows a copy is a second system to reconcile. ### Parent Portal ### Resident Portal ### Tenant Portal ### Vendor Portal ## Running the place Work orders, assets, access, and the front desk. The operational half of a building, a campus, or a property, tracked to closure rather than to a spreadsheet. ### Facilities ### Maintenance ### Building Management ### Defects ### Access ### Car Park ### Front Desk ### Appointments ## Out on the road Dispatch, the driver's tool, and the depot behind them, built to keep recording where coverage fails rather than to fall back on handwriting. ### Dispatch ### Driver App ### Hub ### Consignments ## Public service delivery Applications, approvals, and enforcement, with the status the applicant can see and the evidence an examiner will ask for. ### Licensing ### Enforcement ### Document AI Where the suite stops ### A layer, not a replacement for everything under it asasii does not replace a general ledger, a clinical system, a core banking platform, or a building’s mechanical controls. Those are specialist domains with their own vendors and their own regulatory footing, and the right posture towards them is a well designed interface rather than an attempt at replacement. What the suite covers is the operational layer between them: where money is taken, what is owed, what was delivered, and who can see it. [Tell us what you need built](https://idataraya.com/contact/) ## Explore More Field note ### The engines we compose every system from [Read the note](https://idataraya.com/insights/the-asasii-suite/) [Industries The sectors these modules run in](https://idataraya.com/industries/) [Capabilities What we engineer and operate](https://idataraya.com/capabilities/) --- --- title: "Capabilities | idataraya" description: "The capabilities idataraya builds and operates, from payment acceptance to applied AI." url: "https://idataraya.com/capabilities/" --- Capabilities # Capabilities Learn more about our core areas of expertise and how we put them to work. [Payments and Acceptance](https://idataraya.com/capabilities/payments-and-acceptance/) [Payment Hardware](https://idataraya.com/capabilities/payment-hardware/) [Business Systems](https://idataraya.com/capabilities/business-systems/) [Payroll and HR Systems](https://idataraya.com/capabilities/payroll-and-hr/) [Artificial Intelligence](https://idataraya.com/capabilities/artificial-intelligence/) [Mobile Applications](https://idataraya.com/capabilities/mobile-applications/) [Digital and Technology](https://idataraya.com/capabilities/digital-and-technology/) [Data and Analytics](https://idataraya.com/capabilities/data-and-analytics/) [Cloud and Infrastructure](https://idataraya.com/capabilities/cloud-and-infrastructure/) [Security](https://idataraya.com/capabilities/security/) [Business Resilience](https://idataraya.com/capabilities/business-resilience/) [Operations](https://idataraya.com/capabilities/operations/) [Risk Management and Compliance](https://idataraya.com/capabilities/risk-management-and-compliance/) --- --- title: "Industries | idataraya" description: "The industries idataraya serves with payment acceptance and business systems in Malaysia." url: "https://idataraya.com/industries/" --- # Our Industries idataraya draws on deep industry expertise to make companies more competitive: payment acceptance at the counter, business systems behind it, and applied AI inside both, built and operated for the industries that keep Malaysia running. [Financial Institutions](https://idataraya.com/industries/financial-institutions/) [Retail](https://idataraya.com/industries/retail/) [Public Sector](https://idataraya.com/industries/public-sector/) [Health Care](https://idataraya.com/industries/health-care/) [Education](https://idataraya.com/industries/education/) [Travel and Tourism](https://idataraya.com/industries/travel-tourism/) [Transportation and Logistics](https://idataraya.com/industries/transportation-logistics/) [Property Developers](https://idataraya.com/industries/property-developers/) [Malls and Commercial Property](https://idataraya.com/industries/commercial-property/) [Strata and Condominium](https://idataraya.com/industries/strata-management/) ## Explore Our Latest Thinking All topics [Health Care Field note7 November 2026 The front desk is not an integration layer Read](https://idataraya.com/insights/front-desk-integration-layer/) [Public Sector Field note24 October 2026 Audit evidence is a feature, not a report you run later Read](https://idataraya.com/insights/audit-evidence/) [Public Sector Field note10 October 2026 What tender documents get wrong about maintenance Read](https://idataraya.com/insights/tendering-for-maintenance/) [Retail Field note26 September 2026 The online store that sells what the counter already sold Read](https://idataraya.com/insights/online-store-oversell/) [Retail Field note12 September 2026 One catalogue, or the argument you have every month Read](https://idataraya.com/insights/one-catalogue/) [Transportation and Logistics Field note2 September 2026 Anything that assumes a signal at the door will produce paper at the depot Read](https://idataraya.com/insights/signal-at-the-door/) [Strata and Condominium Field note2 April 2026 Arrears are a process, and the process needs a trail Read](https://idataraya.com/insights/arrears-need-a-trail/) [Strata and Condominium Field note19 March 2026 Whose records are they when the managing agent changes Read](https://idataraya.com/insights/whose-records-managing-agent/) [Malls and Commercial Property Field note5 March 2026 The building outlives every system bought for it Read](https://idataraya.com/insights/building-outlives-its-systems/) [Malls and Commercial Property Field note19 February 2026 Billing errors do not start in billing, they start in the lease Read](https://idataraya.com/insights/billing-starts-in-the-lease/) [Property Developers Field note5 February 2026 Progressive billing belongs with certification, not beside it Read](https://idataraya.com/insights/progressive-billing-certification/) [Property Developers Field note22 January 2026 Vacant possession is where developers lose their own data Read](https://idataraya.com/insights/vacant-possession-data/) 1 2 --- --- title: "Field notes | idataraya" description: "idataraya's latest thinking on payments, applied AI, and the systems businesses run on." url: "https://idataraya.com/insights/" --- # Featured Insights and Perspectives from idataraya **The latest insights, ideas, and perspectives from idataraya.** Explore a cross-section of up-to-date thinking on payments, applied AI, and the systems Malaysian businesses run on. ## Most Recent Insights All topics [Platform Field note10 December 2026 The asasii suite: production engines we compose every system from Read](https://idataraya.com/insights/the-asasii-suite/) [Perspective Field note26 November 2026 We build, and we maintain: inside the idataraya engagement model Read](https://idataraya.com/insights/the-engagement-model/) [Integration Field note12 November 2026 What breaks in a bank integration, and roughly when Read](https://idataraya.com/insights/what-breaks-in-bank-integrations/) [Health Care Field note7 November 2026 The front desk is not an integration layer Read](https://idataraya.com/insights/front-desk-integration-layer/) [Operations Field note29 October 2026 Taking over a system you did not build: the first ninety days Read](https://idataraya.com/insights/inheriting-a-system/) [Public Sector Field note24 October 2026 Audit evidence is a feature, not a report you run later Read](https://idataraya.com/insights/audit-evidence/) [Business Resilience Field note15 October 2026 Degrading well beats recovering fast Read](https://idataraya.com/insights/degrading-well/) [Public Sector Field note10 October 2026 What tender documents get wrong about maintenance Read](https://idataraya.com/insights/tendering-for-maintenance/) [Security Field note1 October 2026 Account recovery is usually the softest way in Read](https://idataraya.com/insights/account-recovery-soft-way-in/) [Retail Field note26 September 2026 The online store that sells what the counter already sold Read](https://idataraya.com/insights/online-store-oversell/) [Security Field note18 September 2026 Controls that depend on discipline fail during busy weeks Read](https://idataraya.com/insights/controls-that-need-discipline/) [Retail Field note12 September 2026 One catalogue, or the argument you have every month Read](https://idataraya.com/insights/one-catalogue/) 1 2 3 4 ## Featured Campaigns and Collections [Capability The Soundbox Shift](https://idataraya.com/capabilities/payment-hardware/) [Capability AI in the Workflow](https://idataraya.com/capabilities/artificial-intelligence/) [Collection The Build and Run Papers](https://idataraya.com/capabilities/operations/) [Collection Settlement and the Morning Ritual](https://idataraya.com/capabilities/payments-and-acceptance/) [Platform The asasii Suite](https://idataraya.com/asasii/) [Collection Records a Community Owns](https://idataraya.com/industries/strata-management/) --- --- title: "Contact | idataraya" description: "Reach idataraya about a system to build, one to take over, a partnership, or a role." url: "https://idataraya.com/contact/" --- # How can we help? Most enquiries have a faster route than a form. Find yours below, or write to us at the bottom of the page and an engineer will read it. ## New enquiries You have a system to build, or one you need someone to take over and run. Tell us what it does and what breaks. Send us a message ## Existing clients Support for a system we already run for you. Use the channel in your engagement first, since it reaches the team on duty. Raise an enquiry ## Careers Open roles, graduate places and internships, with an application read by the engineers you would work with. [idataraya careers](https://idataraya.com/careers/) ## Partners and suppliers Hardware, payment rails, and the vendors behind the systems we deliver. Tell us where you fit. Get in touch ## Media Questions about the company, the work, or the systems we operate. We answer what we can say. Media enquiries ## Need something else? One form for everything the routes above do not cover. An engineer reads it, and you get an answer either way. What is this about Choose a topic ### About you Full name Email Phone*Optional* Organisation Your role*Optional* How can we help? I agree to idataraya holding these details to answer this enquiry, as set out in the privacy policy. [Privacy policy](https://idataraya.com/privacy-policy/) Send enquiry ## More ways to get in touch ### Call us +60 19 220 0501 Monday to Friday, Malaysian office hours. ### Email us info@idataraya.com For anything that does not need a form. ### Find us Kuala Lumpur, Malaysia Most work happens on client sites across the peninsula and East Malaysia. --- --- title: "idataraya API and agent documentation | idataraya" description: "The idataraya developer reference: public JSON API, OpenAPI specification, llms.txt, markdown content negotiation, and the endpoints for sending an enquiry or an application." url: "https://idataraya.com/developers/" --- Developers # idataraya API and agent documentation Everything on this page is public. There is no key to request, no account to create, and no rate limit: the read-only endpoints are static JSON files served from a CDN. If you are an automated client, start at [the resource list](https://idataraya.com/developers/#resources) and read [/llms.txt](https://idataraya.com/llms.txt) first. ## Machine-readable resources - [/openapi.json](https://idataraya.com/openapi.json) — OpenAPI 3.1 description of every endpoint below, with an operation ID, a description and a response schema on each one. Load this directly into a function-calling client. - [/api/v1/index.json](https://idataraya.com/api/v1/index.json) — Discovery document. Lists every endpoint in the API with its absolute URL, so nothing has to be guessed from a base path. - [/llms.txt](https://idataraya.com/llms.txt) — What idataraya is, when to reach for it, and a map of the site as markdown, in the llmstxt.org format. - [/llms-full.txt](https://idataraya.com/llms-full.txt) — Every published page concatenated as one markdown document, for loading the whole site into a context window at once. - [/sitemap.xml](https://idataraya.com/sitemap.xml) — Every indexable URL on the site. - [/robots.txt](https://idataraya.com/robots.txt) — Crawl policy, including which automated clients are allowed where. ## When to use idataraya idataraya is a Malaysian software engineering company. It designs, builds, deploys and operates the systems organisations run their work on, and stays accountable for them in production. Reach for it when one of these is the job: - **A payment, acceptance or settlement system has to be built or taken over.** Card, DuitNow QR and e-wallet acceptance, terminal and kiosk software, settlement and reconciliation. This is the work idataraya does most of, and the reconciliation and integration detail is published rather than summarised. - **An organisation in Malaysia needs an operational system built and then run.** CRM, billing and collections, vendor and supplier portals, counter and kiosk software, payroll and HR. One team designs, builds, deploys and stays accountable for it in production, rather than handing it to a second vendor. - **An existing system needs to be taken over and operated.** Inheriting a system someone else built, stabilising it, and running it. Ask about Operations rather than about a new build. - **Someone is evaluating idataraya as a supplier.** Named engagements with measured outcomes are published under client impact, and the capability and industry records say what the company does and does not take on. What it is not the right answer to: - Buying a licence for off-the-shelf software. idataraya builds and operates systems; it does not sell seats. - Anything outside Malaysia and the region it serves. Check area\_served on the organization endpoint before recommending it. - Live account, order or transaction data. This API publishes what the company publishes, not any client's operational data, and no endpoint here is authenticated because none of it is private. To act on any of these, either send the person to [the contact page](https://idataraya.com/contact/) or POST an enquiry to `/api/contact`, described below. ## Content API Every endpoint is `GET`, returns `application/json`, and needs no headers. Collections are never paginated: `count` is the whole set. - [/api/v1/organization.json](https://idataraya.com/api/v1/organization.json) — The company: description, contact, address, languages. - [/api/v1/capabilities.json](https://idataraya.com/api/v1/capabilities.json) — What idataraya engineers and operates. - [/api/v1/industries.json](https://idataraya.com/api/v1/industries.json) — The sectors it builds and runs systems in. - [/api/v1/client-impact.json](https://idataraya.com/api/v1/client-impact.json) — Named client engagements and what they produced. - [/api/v1/insights.json](https://idataraya.com/api/v1/insights.json) — Published field notes, full text included. Detail records hang off the collections at `/api/v1/{collection}/{slug}.json`. Each list response carries the exact `api_url` of every record, so the pattern never has to be assembled by hand. ## Markdown instead of HTML Every page on this site has a markdown representation of the same content. There are two ways to ask for it, and they return the same bytes: - Send `Accept: text/markdown` to the normal page URL. The response comes back as `text/markdown; charset=utf-8` with `Vary: Accept`. - Append `.md` to the path: [/about.md](https://idataraya.com/about.md). HTML pages advertise their markdown twin in a `Link: <…>; rel="alternate"; type="text/markdown"` response header. Prefer markdown over parsing the HTML: it is the same content without the navigation, and it is what this site is set up to serve you. ## Sending an enquiry or an application Two endpoints accept a `POST`. Both deliver email to a person and neither stores or returns a record, so a call cannot be read back or undone. - `POST /api/contact` — an enquiry. Requires `topic`, `name`, `email`, `organisation` and `message`. The `topic` must match one of the values listed in the OpenAPI schema exactly. - `POST /api/apply` — a job application, optionally with a CV attached as base64. Open roles are listed at [careers.idataraya.com](https://careers.idataraya.com). If you are acting for someone else, send only their own details, with their agreement, and only when they have actually asked to be put in touch. ## Rate limits Every response under `/api`, and the machine-readable files above, carry `RateLimit-Policy` and `RateLimit-Limit` headers declaring an advisory ceiling of 60 requests per minute per client. The read-only surface is static files on a CDN, so there are no per-client counters and no `RateLimit-Remaining` header: the declaration is the policy, not a live quota. Stay under it and you will never be throttled. If the edge does throttle a burst, the `429` carries `Retry-After` in seconds. Honour it and retry once; do not tighten the loop. ## Versioning and deprecation The API is versioned in the URL path: everything today is `/api/v1`. Within a version, changes are additive only. Fields and endpoints are added; nothing is renamed, removed, or changed in meaning. A response gaining a new field is normal and your client should ignore fields it does not recognise. A breaking change ships as `/api/v2` alongside `v1`, never in place of it. When a version is scheduled for retirement, every response from it gains a `Deprecation` header and a `Sunset` header naming the removal date, at least six months ahead, and the change is announced on this page and in [/llms.txt](https://idataraya.com/llms.txt). No version is removed while its responses carry no `Sunset` header, so the absence of the header is itself the signal that the surface is stable to build on. ## Errors Every failure under `/api` is JSON, never an HTML page. Bodies carry a stable `code`, a `message`, a `hint` naming the next thing to try, and `documentation_url`. A `404` means the slug does not exist: fetch the collection and read the real slugs rather than retrying a guess. ## Something missing? If you need a field, an endpoint or a format that is not here, write to info@idataraya.com or use [the contact page](https://idataraya.com/contact/). Security issues go through [responsible disclosure](https://idataraya.com/responsible-disclosure/) instead. --- --- title: "Site map | idataraya" description: "Every section and page of the idataraya website." url: "https://idataraya.com/sitemap/" --- [Home](https://idataraya.com/) Our Services [Industries](https://idataraya.com/industries/) - [Financial Institutions](https://idataraya.com/industries/financial-institutions/) - [Retail](https://idataraya.com/industries/retail/) - [Public Sector](https://idataraya.com/industries/public-sector/) - [Health Care](https://idataraya.com/industries/health-care/) - [Education](https://idataraya.com/industries/education/) - [Travel and Tourism](https://idataraya.com/industries/travel-tourism/) - [Transportation and Logistics](https://idataraya.com/industries/transportation-logistics/) - [Property Developers](https://idataraya.com/industries/property-developers/) - [Malls and Commercial Property](https://idataraya.com/industries/commercial-property/) - [Strata and Condominium](https://idataraya.com/industries/strata-management/) [Capabilities](https://idataraya.com/capabilities/) - [Payments and Acceptance](https://idataraya.com/capabilities/payments-and-acceptance/) - [Payment Hardware](https://idataraya.com/capabilities/payment-hardware/) - [Business Systems](https://idataraya.com/capabilities/business-systems/) - [Payroll and HR Systems](https://idataraya.com/capabilities/payroll-and-hr/) - [Artificial Intelligence](https://idataraya.com/capabilities/artificial-intelligence/) - [Mobile Applications](https://idataraya.com/capabilities/mobile-applications/) - [Digital and Technology](https://idataraya.com/capabilities/digital-and-technology/) - [Data and Analytics](https://idataraya.com/capabilities/data-and-analytics/) - [Cloud and Infrastructure](https://idataraya.com/capabilities/cloud-and-infrastructure/) - [Security](https://idataraya.com/capabilities/security/) - [Business Resilience](https://idataraya.com/capabilities/business-resilience/) - [Operations](https://idataraya.com/capabilities/operations/) - [Risk Management and Compliance](https://idataraya.com/capabilities/risk-management-and-compliance/) [The asasii Suite](https://idataraya.com/asasii/) - [Taking the money](https://idataraya.com/asasii/#acceptance) - [Selling and stock](https://idataraya.com/asasii/#commerce) - [What is owed, and what arrived](https://idataraya.com/asasii/#money) - [One record per person, parcel, or unit](https://idataraya.com/asasii/#records) - [The other party's own view](https://idataraya.com/asasii/#portals) - [Running the place](https://idataraya.com/asasii/#operations) - [Out on the road](https://idataraya.com/asasii/#field) - [Public service delivery](https://idataraya.com/asasii/#public) [Our Insights](https://idataraya.com/insights/) - [All field notes](https://idataraya.com/insights/) - [How we work](https://idataraya.com/about/) - [Talk to an engineer](https://idataraya.com/contact/) - [Settlement files never agree on the first pass](https://idataraya.com/insights/settlement-files/) - [The timeout with an unknown outcome](https://idataraya.com/insights/timeout-unknown-outcome/) - [The workarounds are the requirements](https://idataraya.com/insights/workarounds-are-requirements/) - [An untested restore is a belief, not a backup](https://idataraya.com/insights/untested-restore/) - [Anything that assumes a signal at the door will produce paper at the depot](https://idataraya.com/insights/signal-at-the-door/) - [One catalogue, or the argument you have every month](https://idataraya.com/insights/one-catalogue/) - [The online store that sells what the counter already sold](https://idataraya.com/insights/online-store-oversell/) - [What tender documents get wrong about maintenance](https://idataraya.com/insights/tendering-for-maintenance/) - [Audit evidence is a feature, not a report you run later](https://idataraya.com/insights/audit-evidence/) - [The front desk is not an integration layer](https://idataraya.com/insights/front-desk-integration-layer/) - [The soundbox is the simplest trust upgrade in Malaysian acquiring](https://idataraya.com/insights/soundbox-trust-upgrade/) - [Your terminal estate is a logistics business. Run it like one.](https://idataraya.com/insights/provisioning-a-terminal-fleet/) - [Claims do not fail at submission, they fail at follow-up](https://idataraya.com/insights/claims-follow-up/) - [Semester close is a systems problem, not a finance problem](https://idataraya.com/insights/semester-close/) - [The same student, twice, and the fee nobody is chasing](https://idataraya.com/insights/duplicate-student-records/) - [Your outlets are separate businesses sharing one balance sheet](https://idataraya.com/insights/outlets-one-balance-sheet/) - [Seasonal hiring is a software requirement](https://idataraya.com/insights/seasonal-hiring-software/) - [Cash on delivery is a control problem before it is a payments problem](https://idataraya.com/insights/cash-on-delivery-control/) - [Vacant possession is where developers lose their own data](https://idataraya.com/insights/vacant-possession-data/) - [Progressive billing belongs with certification, not beside it](https://idataraya.com/insights/progressive-billing-certification/) - [Billing errors do not start in billing, they start in the lease](https://idataraya.com/insights/billing-starts-in-the-lease/) - [The building outlives every system bought for it](https://idataraya.com/insights/building-outlives-its-systems/) - [Whose records are they when the managing agent changes](https://idataraya.com/insights/whose-records-managing-agent/) - [Arrears are a process, and the process needs a trail](https://idataraya.com/insights/arrears-need-a-trail/) - [Parallel running is not caution, it is the test](https://idataraya.com/insights/parallel-running-is-the-test/) - [Most payroll errors are entered, not calculated](https://idataraya.com/insights/payroll-errors-are-entered/) - [Automating a step nobody was waiting on](https://idataraya.com/insights/automating-the-wrong-step/) - [If nobody can check the answer, it cannot go into production](https://idataraya.com/insights/checkable-answers/) - [Test on the phones your staff actually carry](https://idataraya.com/insights/test-on-real-phones/) - [The warehouse is rarely the problem: where reporting actually breaks](https://idataraya.com/insights/where-reporting-breaks/) - [Integration is not the plumbing, it is the building](https://idataraya.com/insights/integration-is-the-building/) - [Two people, two numbers, and the end of a dashboard](https://idataraya.com/insights/two-people-two-numbers/) - [Rare releases are large releases](https://idataraya.com/insights/rare-releases-are-large/) - [The third-year cloud bill](https://idataraya.com/insights/third-year-cloud-bill/) - [Controls that depend on discipline fail during busy weeks](https://idataraya.com/insights/controls-that-need-discipline/) - [Account recovery is usually the softest way in](https://idataraya.com/insights/account-recovery-soft-way-in/) - [Degrading well beats recovering fast](https://idataraya.com/insights/degrading-well/) - [Taking over a system you did not build: the first ninety days](https://idataraya.com/insights/inheriting-a-system/) - [What breaks in a bank integration, and roughly when](https://idataraya.com/insights/what-breaks-in-bank-integrations/) - [We build, and we maintain: inside the idataraya engagement model](https://idataraya.com/insights/the-engagement-model/) - [The asasii suite: production engines we compose every system from](https://idataraya.com/insights/the-asasii-suite/) Our Company - [About idataraya](https://idataraya.com/about/) - [Careers](https://idataraya.com/careers/) - [Payment Hardware](https://idataraya.com/capabilities/payment-hardware/) - [Contact](https://idataraya.com/contact/) - [Developers and agents](https://idataraya.com/developers/) Legal - [Accessibility](https://idataraya.com/accessibility/) - [Cookie Policy](https://idataraya.com/cookie-policy/) - [Privacy Policy](https://idataraya.com/privacy-policy/) - [Responsible Disclosure](https://idataraya.com/responsible-disclosure/) - [Site Map](https://idataraya.com/sitemap/) - [Terms Of Use](https://idataraya.com/terms/) [Join Us](https://idataraya.com/careers/) --- --- title: "Accessibility | idataraya" description: "How idataraya.com is built for accessibility, the standard we work to, and the limitations we know about." url: "https://idataraya.com/accessibility/" --- Legal # Accessibility Statement Last updated: August 2026 ## Our Commitment idataraya builds software that public sector bodies, financial institutions, and enterprises rely on to serve the public. People using those systems have a wide range of abilities, and a system that cannot be operated by some of the people who need it has not been finished. We apply the same standard to this website. This statement sets out what we aim for on idataraya.com, what we have done, what we know is imperfect, and how to tell us when something does not work for you. ## Standard We Work To We design and build this website against the Web Content Accessibility Guidelines (WCAG) 2.1 at Level AA. We treat that as the working target rather than a claim of certified conformance. This site has not been audited by an independent accessibility assessor, and we do not describe it as fully conformant. Where this statement describes what we have done, it describes our own testing and our own judgement. ## What We Have Built In The following are deliberate decisions in how the site is built, not incidental outcomes: - Every page can be operated with a keyboard alone. Interactive controls are reachable in a logical order, and the element with keyboard focus is always visibly indicated. - A skip link is the first focusable item on every page, so keyboard and screen reader users can bypass the header and menu and go straight to the main content. - Pages use real headings, lists, navigation landmarks, and buttons rather than styled substitutes, so assistive technology can present the structure of a page accurately. - Images that carry meaning have text alternatives. Images that are purely decorative are hidden from assistive technology so they do not add noise. - Body text and interface text are checked against WCAG AA contrast ratios against the background they sit on. - Text reflows and remains readable when the page is zoomed or viewed on a small screen, without content being cut off or requiring horizontal scrolling. - Animation and motion effects are disabled automatically when your device or browser is set to reduce motion. Content is shown immediately in its final state instead. - Controls that expand, collapse, or open menus report their state to assistive technology, so their current condition is announced rather than left to be inferred visually. ## Known Limitations We would rather record the gaps than imply there are none. We are aware of the following: - This site has not been through an independent accessibility audit, and it has not been formally tested against the full range of screen readers, magnifiers, and input devices in use. - Documents offered for download, including PDFs, may not meet the same standard as the pages of this site. If a document you need is not accessible to you, contact us and we will provide the content in an alternative format. - Content, images, or embedded material supplied by third parties may not meet WCAG 2.1 Level AA. We do not control how that material is produced. - Where new pages and sections are published, accessibility issues may be introduced before we catch them. Reports from people using the site are how we find these fastest. ## Tell Us About A Barrier If any part of this website prevents you from doing what you came to do, we want to hear about it, and you do not need to identify the technical cause. Tell us the page, what you were trying to do, and what happened. If you use assistive technology, telling us which one and on what device helps us reproduce the problem. Write to us at info@idataraya.comCopy. We will acknowledge your message, tell you what we find, and where we can provide the information you needed in a format that works for you while we fix the underlying issue. ## Reviewing This Statement We review this statement when we make significant changes to the website, and we revise the "Last updated" date when we do. Where a limitation recorded above has been resolved, we remove it rather than leave it standing. --- --- title: "Cookie Policy | idataraya" description: "idataraya.com sets no analytics, advertising, or tracking cookies. What that means and the one exception for security." url: "https://idataraya.com/cookie-policy/" --- Legal # Cookie Policy Last updated: August 2026 ## Summary idataraya.com does not set analytics cookies, advertising cookies, or tracking cookies. We do not run third party analytics, advertising networks, social media pixels, or session recording tools on this website. There is no cookie consent banner on this site because there is nothing for you to consent to. This policy explains what that means in practice, the limited exception for security, and how to verify any of it for yourself. ## What A Cookie Is A cookie is a small text file that a website asks your browser to store and send back on later visits. Cookies are commonly used to keep you signed in, to remember preferences, to measure how many people visit a site and what they do there, and to build advertising profiles across different websites. Websites can also store information in your browser without using cookies, through mechanisms such as local storage and session storage. This policy covers those too, because the privacy question is the same regardless of the technical method. ## What This Website Does Not Do On the public pages of idataraya.com: - We do not set analytics or measurement cookies. We do not use Google Analytics or any comparable product. - We do not set advertising or retargeting cookies, and we do not embed advertising network tags. - We do not embed social media tracking pixels, and we do not load social platform scripts that would identify you to those platforms. - We do not use session recording, heatmapping, or behavioural profiling tools. - We do not store information about you in your browser's local storage or session storage. - We do not build a profile of you across websites, and we have nothing to sell or share with data brokers. ## The Exception: Security And Delivery This website is delivered through a content delivery network, which serves the pages to you from a location near you and protects the site from attack and automated abuse. To do that, the provider may set strictly necessary cookies in your browser, for example to distinguish a genuine visitor from automated traffic during a security check. These cookies exist to keep the site available and are not used by idataraya to identify you, to measure your behaviour, or for marketing. They are set by the infrastructure that delivers the site rather than by anything we have added to the pages. Because they are strictly necessary for the service you have requested, they do not require consent under the applicable rules. Our provider also processes standard server request information such as IP address and browser type for security and delivery purposes. This is described further in our Privacy Policy. ## Forms And Enquiries When you submit an enquiry through this website, the information you type into the form is sent to us so that we can respond to you. That is a direct consequence of you choosing to contact us, and it does not involve tracking cookies. How we handle the information you send is set out in our Privacy Policy. ## Other idataraya Systems This policy covers the public website at idataraya.com only. Software that idataraya builds and operates for clients, and any signed in application or portal, will use cookies where they are needed for the service to function, for example to keep a session open and to protect an authenticated account. Those systems carry their own notices, and this policy does not describe them. ## Controlling Cookies In Your Browser Every major browser lets you view stored cookies, delete them, and block them, either for all sites or for a specific site. These controls are found in your browser's privacy or security settings. You can also use your browser's developer tools to inspect exactly what this site stores in your browser, which is the most direct way to verify what this policy states. Blocking all cookies for this site will not prevent you from reading it. It may, in some circumstances, cause the security check described above to be repeated. ## Changes To This Policy If we ever introduce cookies beyond those described here, for example analytics, we will update this policy, revise the "Last updated" date, and put appropriate consent controls in place before those cookies are set. We will not add tracking quietly and describe it afterwards. ## Contact If you have a question about this policy, or you believe this site has stored something in your browser that is not described here, write to us at privacy@idataraya.comCopy and tell us what you found. --- --- title: "Privacy Policy | idataraya" description: "How idataraya collects, uses, and protects personal information." url: "https://idataraya.com/privacy-policy/" --- Legal # Privacy Policy Last updated: July 2026 ## Introduction This Privacy Policy explains how idataraya and its affiliates ("idataraya", "we", "us", or "our") collect, use, disclose, and protect your personal data. idataraya is a Malaysian technology company that provides payment systems, business software, and related devices to businesses and their customers. We understand that your privacy matters, and we are committed to handling your personal data responsibly and in accordance with the Personal Data Protection Act 2010 of Malaysia (the "PDPA") and its subsidiary legislation. This Privacy Policy is issued in accordance with the notice and choice principle under the PDPA. It sets out the purposes for which we process your personal data, the parties to whom we may disclose it, and the rights available to you. Please read it carefully so that you understand our practices. In this Privacy Policy, "personal data" means information that relates directly or indirectly to you and that can identify you, whether on its own or when combined with other information in our possession. It has the meaning given to it under the PDPA. ## Scope This Privacy Policy applies to personal data that we collect and process when you: - Access or use idataraya.com or any other website, portal, or application operated by idataraya that links to this Privacy Policy (together, the "Site"). - Register for an account, subscribe to updates, or request information about our products and services. - Engage with us as a client, business contact, supplier, partner, or prospective client. - Attend our events, respond to our surveys, or visit our offices. - Otherwise interact with idataraya in the course of our business activities. Where idataraya processes personal data on behalf of a client as a data processor (for example, when we operate a payment or software service for that client and process the personal data of the client's own customers under the client's instructions), the client's own privacy notice governs that processing, and this Privacy Policy does not apply. This Privacy Policy may be supplemented by additional notices that we provide at the point of collection or in connection with a specific product, service, or relationship. Where an additional notice applies, it should be read together with this Privacy Policy. ## How We Handle Personal Data: PDPA Principles We seek to process your personal data in line with the personal data protection principles set out in the PDPA. In summary: - General principle: we process personal data only with your consent or where processing is otherwise permitted under the PDPA, and we do not process it in a way that is incompatible with the purposes for which it was collected. - Notice and choice principle: we inform you, through this Privacy Policy and any specific notices, of the personal data we collect, the purposes of processing, and your right of access and correction. - Disclosure principle: we disclose personal data only for the purposes described in this Privacy Policy or a directly related purpose, and to the classes of parties identified here, unless you consent otherwise or disclosure is permitted by law. - Security principle: we take practical steps to protect personal data from loss, misuse, unauthorised access, alteration, or disclosure. - Retention principle: we retain personal data only for as long as necessary to fulfil the purposes for which it was collected or as required by law, and we take reasonable steps to dispose of it when it is no longer needed. - Data integrity principle: we take reasonable steps to keep personal data accurate, complete, not misleading, and up to date, having regard to the purposes for which it is processed. - Access principle: we give you the ability to request access to, and correction of, the personal data we hold about you, subject to the exceptions permitted under the PDPA. ## Changes to This Policy idataraya may amend this Privacy Policy at any time and at our discretion, for example to reflect changes in our business, in technology, or in applicable law. When we make changes, we will post the updated Privacy Policy on the Site and revise the "Last updated" date at the top. Where the changes are significant, we may provide additional notice, such as a notice on the Site or a message to your registered email address. Your continued access to or use of the Site or our services after an updated Privacy Policy takes effect signifies your acknowledgement of the changes, to the extent permitted by law. We encourage you to review this Privacy Policy from time to time. ## Personal Information We Collect The personal data we collect depends on how you interact with us. We collect personal data directly from you, automatically through your use of the Site and our services, and from third parties and publicly available sources, as described below. Account and registration information When you create an account, register for parts of the Site, subscribe to newsletters or updates, request publications, or ask for information about our products and services, we collect the details you provide. This may include your name, email address, telephone number, postal address, username and password, job title, employer, and the subject areas or products you are interested in. If you choose not to provide certain personal data, we may be unable to create your account, complete your registration, respond to your request, or provide the product or service you have asked for. Business contacts, clients, suppliers, and partners In the course of our business relationships, we collect and maintain personal data about our clients, prospective clients, suppliers, partners, and their personnel. This may include names, business contact details, job titles and roles, correspondence with us, transaction and account records, billing and payment details, and information relevant to the products and services we provide or are considering providing. Where you provide us with personal data about another individual (for example, a colleague or a contact within your organisation), you confirm that you are authorised to share that data with us and that the individual is aware of and, where required, has consented to our processing of their personal data in accordance with this Privacy Policy. Events and surveys When you register for or attend our events, webinars, or product demonstrations, or when you take part in our surveys, we collect information such as your name, email address, telephone number, employer and job title, areas of interest, and any dietary or accessibility requirements you tell us about. At certain events we may collect photographs, video, or audio recordings, and we will let you know where this is the case. Device and usage data When you access the Site or use our products and services, we automatically collect certain technical information. This may include your IP address, device and browser type, operating system, device identifiers, language settings, the pages you view, the links you click, the dates and times of your visits, referring and exit pages, and general location derived from your IP address. For our payment systems, business software, and devices, we may also collect operational and diagnostic data such as transaction metadata, error and event logs, performance metrics, and configuration information. This helps us operate, secure, support, and improve our products and services. Where such operational data relates to an identifiable individual, we handle it as personal data under this Privacy Policy. Cookies and similar technologies We use cookies and similar tracking technologies on the Site and in some of our communications. Please see the "Cookies and Tracking" section below for more detail. Office visitors and security systems When you visit our offices, you may be asked to sign in at reception, and we may collect your name, organisation, contact details, and, where appropriate, identification details for security purposes. We may operate closed-circuit television (CCTV) and other monitoring systems in and around our premises for safety and security, which may capture images and footage of visitors. Publicly available sources and third parties We may collect personal data about you from publicly available sources and from third parties, such as business directories, professional networking and social media platforms, credit reference and fraud prevention agencies where relevant, our business partners, and other data providers. This information may include your name, business contact details, employer, job title, and professional interests. Where we receive personal data from a third party, we take reasonable steps to confirm that the third party is permitted to share it with us. ## How We Use Personal Information We process your personal data for the purposes set out below, in each case where we have your consent or where the processing is otherwise permitted or required under the PDPA or other applicable law. Depending on your relationship with us, not all purposes will apply to you. We use your personal data to: - Create and administer your account and manage your registration, subscriptions, and requests. - Provide, operate, maintain, and support our products and services, including our payment systems, business software, and devices, and to process transactions and provide related customer service. - Communicate with you about your account, your requests, our products and services, service updates, technical notices, and administrative or security messages. - Personalise and improve your experience on the Site and tailor the content, information, and materials we provide to you. - Understand how the Site and our products and services are used, including through analytics, benchmarking, market research, and the analysis of usage trends, so that we can operate and improve them. - Develop new products, services, and features, and test, maintain, repair, and enhance existing ones. - Identify and engage prospective clients, assess business opportunities, and develop, manage, and improve our relationships with clients, suppliers, and partners. - Send you marketing communications about our products, services, events, and offers that may be of interest to you, where you have consented or where we are otherwise permitted to do so. You may opt out of marketing at any time, as described in the "Your Rights under the PDPA" section. - Measure and improve the effectiveness of our marketing and outreach across different channels. - Operate, manage, and secure our facilities, infrastructure, systems, and business. - Protect the safety and security of individuals and property, prevent, detect, and investigate fraud and other unlawful or prohibited activity, verify identity, and safeguard our brand, rights, and legitimate business interests. - Comply with our legal and regulatory obligations, respond to lawful requests from public authorities and courts, and establish, exercise, or defend legal claims. - Facilitate any reorganisation, merger, acquisition, financing, sale, joint venture, or other transfer or disposal of all or part of our business or assets, and to carry out the resulting arrangements. - Create aggregated, anonymised, or de-identified data that no longer identifies you, which we may use for any lawful business purpose. Where we rely on your consent, you may withdraw it at any time as described below. In some cases, processing may continue on another lawful basis permitted by the PDPA, or the withdrawal of consent may prevent us from continuing to provide a product or service to you, and we will let you know where that is the case. ## Disclosure of Personal Information We do not sell your personal data. We may disclose your personal data, for the purposes described in this Privacy Policy, to the following classes of parties: - Our affiliates and group companies, who may process personal data to support our operations and provide our products and services. - Our service providers and contractors who process personal data on our behalf, such as providers of hosting, cloud infrastructure, payment processing, IT and security services, communications and email delivery, analytics, marketing and events support, and professional services. - Our business partners with whom we jointly offer, deliver, or promote products, services, or events, where relevant to your relationship with us. - Our professional advisers, such as legal, financial, audit, and insurance advisers. - Government bodies, regulators, law enforcement agencies, courts, and other authorities, where necessary to comply with a legal obligation, respond to a lawful request, or protect our rights, property, or safety or those of others. - Payment networks, financial institutions, and settlement partners, where necessary to process and settle transactions in connection with our payment products and services. - An actual or prospective buyer, investor, or successor, and their advisers, in connection with any reorganisation, merger, acquisition, financing, sale, joint venture, or other transfer or disposal of all or part of our business or assets. We require our service providers to process personal data only in accordance with our instructions and to keep it secure and confidential. Where we disclose personal data to other parties, we do so only as described in this Privacy Policy, as permitted under the PDPA, or with your consent. ## Cookies and Tracking A cookie is a small file that a website places on your device to store information. We use cookies and similar technologies, such as pixels and tags, to operate the Site, remember your preferences, keep you signed in, understand how the Site is used, and deliver content and marketing that may be relevant to you. We use different categories of cookies, including cookies that are necessary for the Site to function, cookies that help us analyse performance and usage, cookies that remember your preferences, and cookies that support marketing. Some cookies are set by us and some are set by third parties that provide services on our behalf. You can manage cookies through your browser settings, which usually allow you to block or delete cookies or to receive a warning before a cookie is stored. If you disable certain cookies, some parts or features of the Site may not work properly. Where required, we will also request your consent to non-essential cookies through a cookie banner or preference tool on the Site. We do not currently respond to browser "do not track" signals. ## Security In line with the security principle under the PDPA, we take practical technical and organisational steps designed to protect personal data from loss, misuse, and unauthorised access, alteration, or disclosure. These steps may include access controls, encryption where appropriate, network and system security measures, monitoring, and staff confidentiality obligations. Access to personal data is limited to personnel and service providers who need it for the purposes described in this Privacy Policy, and they are subject to a duty of confidentiality. While we take these measures, no method of transmission over the internet or of electronic storage is completely secure, and we cannot guarantee absolute security. You are responsible for keeping your account credentials confidential and for notifying us promptly if you believe your account has been compromised. ## Retention In line with the retention principle under the PDPA, we retain your personal data only for as long as necessary to fulfil the purposes for which it was collected, or for as long as required or permitted by law. The criteria we use to determine retention periods include: - The duration of our relationship with you and the period during which we provide products or services to you or maintain your account. - Whether we have a legal, regulatory, tax, accounting, or contractual obligation to retain the data for a set period. - Whether retention is advisable in light of our legal position, such as applicable limitation periods, disputes, or investigations. - The nature and sensitivity of the personal data and the purposes for which it is processed. When personal data is no longer needed for these purposes, we take reasonable steps to securely delete, destroy, or anonymise it. ## International Transfers idataraya is based in Malaysia, and your personal data is primarily processed and stored in Malaysia. In some cases, personal data may be transferred to, accessed from, or stored in locations outside Malaysia, for example where our affiliates or service providers operate or host systems in other countries. Where we transfer personal data outside Malaysia, we do so in accordance with the PDPA. We take reasonable steps to ensure that the personal data will be afforded a level of protection consistent with the PDPA, for example through contractual protections with the receiving party, or where the transfer is otherwise permitted under the PDPA, such as where you have consented, where the transfer is necessary for the performance of a contract with you, or where another lawful basis for the transfer applies. ## Your Rights under the PDPA Subject to the PDPA and the exceptions it permits, you have the following rights in relation to your personal data: - Access: you may request access to the personal data we hold about you and information about how it is processed. - Correction: you may request that we correct personal data that is inaccurate, incomplete, misleading, or out of date. - Withdrawal of consent: where we process your personal data on the basis of your consent, you may withdraw that consent at any time, although this will not affect processing carried out before the withdrawal, and it may affect our ability to continue providing a product or service to you. - Limiting processing for direct marketing: you may request, at any time, that we stop or limit the processing of your personal data for direct marketing purposes. You can also unsubscribe from our marketing emails using the link provided in each message. To exercise any of these rights, please submit a written request to our Data Protection contact using the details in the "Contact" section below. To help us respond, please tell us clearly which right you wish to exercise and provide enough detail for us to identify your personal data and understand your request. Before we act on a request, we may need to verify your identity, and we may ask you for additional information for this purpose in order to protect your personal data against unauthorised or fraudulent requests. Where the PDPA permits, we may charge a reasonable fee to process a data access request. We aim to respond to your request within the period required under the PDPA. In some cases we may be entitled to decline or limit a request, for example where the PDPA allows us to do so or where granting it would adversely affect the rights of another individual, and we will explain our reasons where we are permitted to do so. ## Marketing Choices If you no longer wish to receive marketing communications from us, you can opt out at any time by using the unsubscribe link included in our marketing emails or by contacting us using the details in the "Contact" section. Even if you opt out of marketing, we may still send you non-marketing messages that are necessary for the administration of your account, transactions, or the products and services you use. ## Children The Site and our products and services are intended for businesses and adults, and are not directed at children. We do not knowingly collect personal data from children without appropriate consent. If you believe that we have collected personal data from a child without the necessary consent, please contact us so that we can take appropriate action. ## Third-Party Sites The Site may contain links to websites, applications, or services that are operated by third parties and that are not controlled by idataraya. We provide these links for convenience, and their inclusion does not imply our endorsement. This Privacy Policy does not apply to third-party sites or services, and we are not responsible for their content, privacy practices, or security. If you access a third-party site or service through a link on the Site, you do so at your own risk, and we encourage you to review the privacy notices of those third parties before providing them with your personal data. ## Contact If you have any questions about this Privacy Policy, wish to exercise your rights, or would like to make a complaint about how we handle your personal data, please contact our Data Protection contact: Data Protection Contact, idataraya, Malaysia. Email: privacy@idataraya.comCopy We will review and respond to your enquiry or complaint in accordance with the PDPA. Where we collect or process your personal data in both the national language and English, the English version of this Privacy Policy is provided for your convenience. ## Governing Law This Privacy Policy and any matter relating to our processing of your personal data are governed by the laws of Malaysia, including the Personal Data Protection Act 2010. You agree that the courts of Malaysia have jurisdiction to hear and determine any dispute arising out of or in connection with this Privacy Policy or our processing of your personal data. --- --- title: "Responsible Disclosure | idataraya" description: "How to report security vulnerabilities to idataraya responsibly." url: "https://idataraya.com/responsible-disclosure/" --- Legal # Responsible Disclosure Program Last updated: July 2026 ## About This Program idataraya builds payment systems, business software, and connected devices used by organisations across Malaysia. We take the security of our products and services seriously, and we recognise that independent security researchers play a valuable role in helping us identify and address weaknesses. This Responsible Disclosure Program sets out how you may report security vulnerabilities to idataraya, the rules you must follow when doing so, and what you can expect from us in return. Please read these terms in full before conducting any testing or submitting a report. Participation in this program is entirely voluntary. It does not create any contract, partnership, employment, or agency relationship between you and idataraya, and it confers no right to payment, reward, or any other form of compensation. idataraya does not operate a paid bug bounty. We may, at our sole discretion, acknowledge researchers who make a valuable and responsible contribution, but any such recognition is optional and is not guaranteed for any report. ## Scope This program applies only to the following assets owned and operated by idataraya: - The public website at idataraya.com and its subdomains. - Publicly accessible web applications hosted by idataraya that are clearly identified as belonging to idataraya. The following are explicitly out of scope, and you must not test, probe, or interact with them under this program: - Production payment infrastructure, payment gateways, transaction processing systems, and any live financial or settlement environment. - Systems, portals, devices, or environments that belong to or are operated on behalf of idataraya clients, partners, or merchants. - Third party services, platforms, and vendors that idataraya uses but does not own or control. - Any system, network, application, or account that is not expressly listed as in scope above. If you are unsure whether an asset is in scope, contact us first and wait for written confirmation before beginning any testing. ## Rules of Engagement To keep testing safe for our users, our systems, and yourself, you must follow all of the rules below. Reports that arise from activity in breach of these rules are not covered by this program. - Access, modify, and interact with only the minimum amount of data needed to demonstrate a vulnerability. Do not access, download, copy, store, or exfiltrate data beyond that minimum. - Never access, alter, or delete data belonging to other users. If you encounter personal data, confidential data, or credentials during testing, stop immediately and report it to us. - Do not perform any denial of service testing, load testing, or volumetric testing, and do not take any action that degrades, disrupts, or damages the availability or integrity of our systems. - Do not conduct social engineering of any kind against idataraya staff, contractors, clients, or users, including phishing, pretexting, or attempts to obtain credentials. - Do not attempt physical access to idataraya premises, offices, hardware, or facilities, and do not target idataraya devices in the field. - Do not test against production payment systems or any live financial environment under any circumstances. - Use only your own test accounts and your own test data. Do not use another person's account without their explicit consent. - Do not introduce malware, backdoors, or any code that persists on or damages our systems, and do not run automated scanners in a way that generates excessive traffic. - Report each vulnerability to us privately and promptly, and give us a reasonable opportunity to investigate and remediate before taking any further action. - Do not publicly disclose any vulnerability, or share it with any third party, until we have confirmed in writing that you may do so. - Comply with all applicable laws at all times, including the Computer Crimes Act 1997 of Malaysia and all other relevant Malaysian legislation. ## Reporting a Vulnerability Send all vulnerability reports to security@idataraya.comCopy. Please submit one report per issue and do not include vulnerability details in any public channel. To help us assess and reproduce the issue quickly, please include the following in your report: - A clear description of the vulnerability and the affected asset, URL, or endpoint. - Step by step instructions to reproduce the issue. - Any proof of concept, request or response samples, or screenshots that support your findings. - An explanation of the potential impact and, if known, suggested remediation. - The date and time of your testing, so we can correlate activity in our logs, and a way for us to contact you if we need further information. Please keep your report factual and avoid including any data belonging to third parties. If you must reference sensitive data to demonstrate impact, redact it as far as possible. ## What to Expect from Us When you report a vulnerability in good faith and in line with these terms, you can expect the following from idataraya: - We aim to acknowledge receipt of your report within five business days. - We will review and validate the report and may contact you for additional detail or clarification. - We will keep you informed of the status of a validated report at reasonable intervals as our investigation progresses. - We will work to remediate confirmed vulnerabilities, prioritising them according to severity and risk. Fix timelines are determined at our discretion and may depend on complexity, dependencies, and operational constraints. - We will treat your report as confidential and will not share your identity with third parties without your consent, unless we are required to do so by law. These are targets and general commitments, not contractual guarantees. Response and remediation times may vary depending on the nature and severity of the issue and on our operational priorities. ## Safe Harbour idataraya will not pursue or support legal action against you for security research and vulnerability reporting carried out in good faith, provided that you fully comply with these terms, including the Scope and Rules of Engagement above. This safe harbour is conditional. It applies only to activity that stays within the defined scope, uses only the minimum access needed to demonstrate an issue, avoids harm to our systems and to third parties, and reports findings to us privately. This safe harbour does not apply to, and idataraya reserves all of its rights in respect of, any activity that breaches these terms, that is conducted in bad faith, that goes beyond the permitted scope, or that violates applicable law. Any protection offered here may be revoked if you breach these rules. Nothing in this program authorises you to act unlawfully. This safe harbour applies only to idataraya. It does not bind any third party, and it does not limit the rights of clients, partners, users, or law enforcement. ## Out of Scope Findings The following types of findings are generally considered low risk or informational and are typically not eligible for recognition under this program, unless you can demonstrate a realistic and material security impact: - Clickjacking on pages that carry no sensitive actions or state changing functionality. - Missing or misconfigured SPF, DKIM, or DMARC records, and other email hardening recommendations without a demonstrated exploit. - Software version banners, server headers, or other disclosure of version information without an associated vulnerability. - Self inflicted cross site scripting, such as self XSS, that cannot be used against another user. - Missing security headers, such as Content Security Policy or HTTP Strict Transport Security, and missing cookie flags on non sensitive cookies, without a demonstrated exploit. - Reports produced solely by automated scanners without validation or a working proof of concept. - Rate limiting, brute force, or account enumeration concerns without a demonstrated security impact. - Denial of service, resource exhaustion, and volumetric issues, which are out of scope by design. - Vulnerabilities that require a compromised, rooted, or jailbroken device, or a highly unlikely user interaction to exploit. ## Legal This program, and any dispute or matter arising from or in connection with it, is governed by and construed in accordance with the laws of Malaysia, and you submit to the jurisdiction of the Malaysian courts. All security testing must comply with applicable law, including the Computer Crimes Act 1997 of Malaysia. Unauthorised access to, or interference with, computer systems or data is a criminal offence, and nothing in this program authorises any unlawful act. By submitting a report, you confirm that your testing complied with these terms and with applicable law, and that your report does not include data unlawfully obtained from any third party. You grant idataraya a perpetual, irrevocable, royalty free right to use, reproduce, and act on the contents of your report for the purposes of investigating and remediating the issue and improving the security of our products and services. idataraya may amend, suspend, or discontinue this program, and may change these terms, at any time and without prior notice. The version published at idataraya.com applies to any report you submit. Continued participation after a change constitutes acceptance of the updated terms. Public disclosure of any vulnerability is permitted only with the prior written consent of idataraya. We ask that you allow a remediation window of at least ninety days from the date we acknowledge your report before any disclosure, and that you coordinate any disclosure with us in writing. ## Contact To report a security vulnerability, or to ask a question about this program, please contact us at security@idataraya.comCopy. Please do not use this address for general support, sales, or account enquiries. Reports that fall outside the scope of this program may not receive a response. --- --- title: "Terms and Conditions of Use | idataraya" description: "The terms that govern use of the idataraya website." url: "https://idataraya.com/terms/" --- Legal # Terms and Conditions of Use Last updated: July 2026 These Terms and Conditions of Use govern your access to and use of the idataraya website at idataraya.com, together with any pages, features, and content made available through it (the Site). The Site is operated by idataraya, a Malaysian technology company providing payment systems, business software, and devices. Please read these terms carefully. They set out the basis on which you may use the Site and form a binding agreement between you and idataraya in relation to that use. ## Acceptance of Terms By accessing, browsing, or otherwise using the Site, you confirm that you have read, understood, and agree to be bound by these terms. If you do not agree to any part of them, you must not access or use the Site. You accept these terms each time you use the Site. Your continued use is treated as your ongoing acceptance of the terms as they apply at the time of that use. If you use the Site on behalf of a company or other organisation, you confirm that you have the authority to bind that organisation to these terms, and references to you include that organisation. You confirm that you are of legal age and have the capacity to enter into a binding agreement under Malaysian law. If you do not have that capacity, you must not use the Site. ## Changes to These Terms idataraya may amend, update, or replace these terms at any time and at its sole discretion. Any changes take effect when the revised terms are posted on the Site, and the "Last updated" date will be adjusted to reflect the most recent version. It is your responsibility to review these terms periodically. Your continued access to or use of the Site after any change is posted constitutes your acceptance of the amended terms. If you do not agree with any change, your sole remedy is to stop using the Site. idataraya is not required to notify you individually of changes to these terms. idataraya may also modify, suspend, or discontinue any part of the Site, including its content, features, or availability, at any time and without notice or liability to you. ## Use of the Site The Site is provided for general information about idataraya and its products and services. Content on the Site is not an offer, a binding quotation, or professional advice, and should not be relied upon as such. Subject to your compliance with these terms, idataraya grants you a limited, personal, non-exclusive, non-transferable, revocable licence to access and view the Site for your own lawful, non-commercial purposes. This licence does not permit any of the following, and you agree that you will not, without the prior written consent of idataraya: - reproduce, republish, distribute, sell, licence, rent, or otherwise commercially exploit any part of the Site or its content - modify, adapt, translate, or create derivative works from the Site or its content - frame, mirror, or embed any part of the Site on another website or service - remove, obscure, or alter any copyright, trademark, or other proprietary notice You are responsible for ensuring that anyone who accesses the Site through your device or internet connection is aware of these terms and complies with them. You are responsible for making all arrangements necessary to access the Site, including compatible equipment and a suitable internet connection, and for any costs you incur in doing so. Any information you submit through the Site must be accurate, current, and not misleading, and you must keep it up to date where the Site allows you to do so. ## Intellectual Property All content on the Site, including text, graphics, logos, icons, images, photographs, illustrations, audio, video, software, page layout, design, and the selection and arrangement of that content, is owned by idataraya or its licensors and is protected by copyright, trademark, and other intellectual property laws of Malaysia and other applicable jurisdictions. The idataraya name, logo, product names, and all related marks are trademarks or trade names of idataraya or its licensors. Nothing on the Site grants you any right or licence to use them without the prior written consent of idataraya or the relevant rights holder. Except for the limited licence expressly granted in these terms, no right, title, or interest in the Site or any of its content is transferred to you. All rights not expressly granted are reserved by idataraya and its licensors. Any use of the Site or its content that is not expressly permitted by these terms may infringe intellectual property rights and other laws and may result in the termination of the licence granted to you. If you provide idataraya with any feedback, suggestions, or ideas about the Site or its products and services, you grant idataraya a perpetual, irrevocable, royalty-free right to use them for any purpose without any obligation or compensation to you. ## Prohibited Conduct You agree to use the Site only for lawful purposes and in a manner that does not infringe the rights of, or restrict or inhibit the use and enjoyment of the Site by, any other party. In particular, you must not: - use the Site in any way that breaches any applicable local, national, or international law or regulation - use the Site for any fraudulent, unlawful, or malicious purpose, or in connection with any unlawful activity - access, scrape, harvest, crawl, index, or collect data from the Site using any automated means, bot, spider, or similar tool, except as expressly permitted in writing by idataraya - reverse engineer, decompile, disassemble, or attempt to derive the source code or underlying structure of any software or component made available through the Site - attempt to gain unauthorised access to the Site, its servers, systems, or any account, network, or data connected to it - introduce or transmit any virus, worm, malware, or other harmful or disruptive code or material - interfere with, disrupt, or place an unreasonable load on the Site or its infrastructure, including through denial-of-service attacks or excessive automated requests - circumvent, disable, or otherwise interfere with any security, authentication, or access-control features of the Site - impersonate idataraya, any of its staff, or any other person, or misrepresent your affiliation with any person or entity - use the Site to transmit unsolicited advertising, spam, or other promotional material, or to collect personal data about other users idataraya reserves the right to investigate any suspected breach of this section and to report activity that it reasonably believes to be unlawful to the relevant authorities and to cooperate with them. ## Third-Party Links and Content The Site may contain links to third-party websites, applications, resources, or content that are not operated or controlled by idataraya. These links are provided for your convenience only. idataraya does not endorse, and is not responsible for, the content, products, services, accuracy, or practices of any third-party website or resource. Accessing any linked site is entirely at your own risk and subject to the terms and policies of that third party. The inclusion of any link does not imply any association, partnership, or endorsement between idataraya and the operator of the linked site. You should review the terms and privacy policies of any third-party site you visit. Any dealings you have with third parties reached through the Site, including the supply of goods, services, or information, are solely between you and that third party, and idataraya is not a party to and has no liability in respect of those dealings. ## Disclaimer of Warranties To the maximum extent permitted by applicable law, the Site and all content, features, and materials made available through it are provided on an "as is" and "as available" basis, without any warranties, representations, or conditions of any kind, whether express, implied, or statutory. idataraya does not warrant or guarantee that: - the Site or its content is accurate, complete, current, reliable, or free from errors or omissions - the Site will be available on an uninterrupted, timely, secure, or error-free basis - the Site or the servers that make it available are free from viruses or other harmful components - any defect or error in the Site will be corrected Any material you access through the Site is accessed at your own discretion and risk, and you are solely responsible for any damage to your systems or loss of data that results from that access. To the extent permitted by law, idataraya disclaims all implied warranties and conditions, including any implied warranties of merchantability, satisfactory quality, fitness for a particular purpose, and non-infringement. ## Limitation of Liability To the maximum extent permitted by applicable law, idataraya, its directors, officers, employees, agents, and licensors will not be liable for any indirect, incidental, special, consequential, punitive, or exemplary loss or damage arising out of or in connection with your use of, or inability to use, the Site. This includes, without limitation, any loss of profit, loss of revenue, loss of business, loss of goodwill, loss of anticipated savings, loss of data, or business interruption, whether arising in contract, tort (including negligence), breach of statutory duty, or otherwise, and whether or not such loss was foreseeable. To the maximum extent permitted by applicable law, the total aggregate liability of idataraya arising out of or in connection with the Site and these terms, whether in contract, tort, or otherwise, is limited to one hundred Malaysian Ringgit (RM100.00). Nothing in these terms limits or excludes idataraya's liability for death or personal injury caused by its negligence, for fraud or fraudulent misrepresentation, or for any other liability that cannot be limited or excluded under applicable Malaysian law. Nothing in these terms excludes, restricts, or modifies any right, guarantee, or remedy that you may have and that cannot be excluded under applicable Malaysian law, including the Consumer Protection Act 1999 where it applies to you. Where liability cannot be excluded but may be limited, idataraya's liability is limited to the minimum extent permitted by applicable law. The limitations in this section reflect a fair allocation of risk between you and idataraya. ## Indemnity You agree to indemnify, defend, and hold harmless idataraya, its directors, officers, employees, agents, and licensors from and against any and all claims, demands, actions, liabilities, losses, damages, costs, and expenses, including reasonable legal fees, arising out of or in connection with: - your use of or access to the Site - your breach of any of these terms - your violation of any applicable law or the rights of any third party - any content or information you submit through the Site idataraya reserves the right, at its own expense, to assume the exclusive defence and control of any matter otherwise subject to indemnification by you, in which case you agree to cooperate with idataraya in asserting any available defence. This indemnity survives the termination of these terms and your use of the Site. ## Suspension and Termination idataraya may, at its sole discretion and without prior notice or liability, suspend, restrict, or terminate your access to all or any part of the Site at any time, including where it reasonably believes that you have breached these terms or applicable law. idataraya may also suspend or withdraw the Site, or any feature of it, for operational, maintenance, security, or business reasons, without notice and without liability to you. Upon any suspension or termination, the licence granted to you under these terms ends immediately, and you must stop using the Site. Any provisions that by their nature should survive termination, including those relating to intellectual property, disclaimers, limitation of liability, and indemnity, will continue to apply. ## Privacy Your use of the Site is also governed by the idataraya Privacy Policy, which explains how idataraya collects, uses, and protects personal data in accordance with the Personal Data Protection Act 2010 of Malaysia and other applicable law. By using the Site, you acknowledge that you have read the Privacy Policy and consent to the handling of your personal data as described in it. The Privacy Policy is available on the Site and forms part of your agreement with idataraya in relation to your use of the Site. ## Governing Law and Jurisdiction These terms and any dispute or claim arising out of or in connection with them, the Site, or their subject matter or formation, including non-contractual disputes or claims, are governed by and construed in accordance with the laws of Malaysia. You agree that the courts of Malaysia have exclusive jurisdiction to settle any dispute or claim arising out of or in connection with these terms or the Site, and you submit to the exclusive jurisdiction of those courts. idataraya makes no representation that the Site or its content is appropriate or available for use in any particular location. If you access the Site from outside Malaysia, you do so on your own initiative and are responsible for compliance with any local laws that apply to you. ## Severability and Waiver If any provision of these terms is found by a court or other competent authority to be invalid, unlawful, or unenforceable, that provision will be severed to the minimum extent necessary, and the remaining provisions will continue in full force and effect. No failure or delay by idataraya in exercising any right or remedy under these terms operates as a waiver of that or any other right or remedy, and no single or partial exercise of any right or remedy prevents any further exercise of it or of any other right or remedy. Any waiver by idataraya of a breach of these terms is effective only if given in writing and does not constitute a waiver of any subsequent breach. These terms, together with the Privacy Policy and any other notices published on the Site, constitute the entire agreement between you and idataraya in relation to your use of the Site and supersede any prior agreement, understanding, or arrangement relating to that use. You may not assign, transfer, or sub-licence any of your rights or obligations under these terms. idataraya may assign or transfer its rights and obligations under these terms at any time without your consent. ## Contact If you have any questions about these Terms and Conditions of Use, or wish to raise any matter concerning your use of the Site, you may contact the idataraya legal team at legal@idataraya.comCopy. --- --- title: "Financial Institutions | idataraya" description: "idataraya builds the payment gateway platform Malaysian financial institutions run under their own brand, composing the APIs they already run into checkout, links, terminals, and merchant tools, then operating it." url: "https://idataraya.com/industries/financial-institutions/" --- # Financial Institutions Malaysian financial institutions already hold the pieces of an acquiring business. The payment APIs exist, the licences exist, the merchant relationships exist. What is missing is the product: the individual APIs sit apart from one another, so there is nothing a merchant can be handed and nothing a relationship manager can sell. idataraya builds the platform that composes those APIs into a payment gateway the institution runs under its own name, from the checkout a merchant embeds to the terminal on the counter and the reader in a toll lane, and then operates it alongside the institution's own teams. The institution keeps the rails, the funds, the records, and the merchant book. We supply the surface merchants use and the layer that connects it to what the institution already runs, deployed in the institution's data centre or its cloud, with processing on the institution's systems or on ours. ## Our Services for Financial Institutions ### Merchant Acquiring Build ### Merchant Estate Rollout ### Managed Fleet Operations ### Merchant Onboarding and Activation ### Settlement and Reconciliation Reporting ### Core Banking and PSP Integration ### Branch and Self-Service Software ## How We Help Financial Institutions A financial institution buying an acquiring platform is really asking four questions before any feature list: whose name is on it, where the money and the data go, where it runs, and who answers when it breaks. The answers here are the institution's name, the institution's systems, the institution's choice of environment, and the same engineers who built it. Expand all Your Brand, Not Ours The platform ships under the institution's name. Merchants see the institution on the checkout, in the merchant app, on the developer portal, and in the SDKs they install. idataraya appears in the contract and in the support arrangement, not in the product a merchant uses. Your Existing APIs, Composed No rip and replace. Most financial institutions already expose payment, account, and customer APIs, but they were built one at a time for different programmes and none of them is a product on its own. We integrate the interfaces already in place and compose them behind one gateway, so the institution keeps its core systems and gains the layer that makes them sellable. Processing Where You Want It Transactions can be processed on the institution's own systems or on ours, decided per deployment rather than fixed by the platform. Where that boundary sits changes which side carries which obligation, so it is settled in design with the institution's risk and compliance teams before anything is built. Deployed Where You Want It The platform runs in the institution's own data centre or on its cloud accounts, whichever the institution's residency and outsourcing position requires. The deployment target is a configuration of the same product, not a different one, so the choice does not cost the institution features. We Build It, Then We Run It After go-live, idataraya operates what it delivers, monitoring the terminal and soundbox estate, handling incidents, and releasing improvements through the institution's change process. Fleet operations run under uptime commitments written into the engagement, so when a soundbox stops announcing payments on a Saturday night, the team that engineered the system is the team fixing it. Business Systems Beyond Acquiring idataraya is Ministry of Finance registered and builds and runs business systems for Malaysian financial institutions and enterprises. Beyond acquiring, that includes CRM, billing and collections, and kiosk and counter software for branch and self-service channels. We follow bank practice throughout: controlled environments, documented change, and operations support that stays with the system in production. ## What This Changes for the Institution Revenue from a book you already hold The merchant relationships, the licences, and the payment rails are already the institution's. What has been missing is something to sell into that book. A gateway under the institution's own brand turns an existing customer base into acquiring revenue, without buying a platform business or handing the relationship to a third party to monetise. One platform instead of scattered APIs Payment, account, and customer APIs built one at a time for different programmes get composed behind a single gateway. Launching the next product becomes a configuration of something the institution already runs rather than another integration programme with its own timeline, budget, and vendor. Self-serve merchant integration Larger merchants integrate against the institution's own developer portal and SDKs instead of waiting for a delivery slot. Onboarding stops being a project per merchant, so the acquiring team can grow the book without growing the queue in front of it. Your rails your data, your control Funds, records, and the merchant relationship stay with the institution. Processing runs on the institution's systems or on ours, and the platform deploys into the institution's data centre or its cloud, so the residency and outsourcing position is the institution's decision rather than a condition of the product. The Shape of It ### An acquiring product line, without becoming a platform business Building this in-house means standing up a product team, a developer experience, a device estate, and an operations function, and then keeping all four staffed. idataraya builds it against the systems the institution already runs, ships it under the institution's name, and stays on to operate it. [Learn more](https://idataraya.com/contact/) ## Our Products and Solutions for Financial Institutions One platform, delivered as parts a financial institution can take in stages. The merchant-facing products carry the institution's brand; the operations products are for the institution's own teams. Every one of them reads and writes through the systems the institution already runs. [Contact the team](https://idataraya.com/contact/) ### Gateway ### Checkout ### Payment Links ### Terminal Suite ### Unattended Terminals ### Merchant App ### Developer Portal ### Onboarding ### Fleet Management ## Our Insights on Payments and Acquiring [See more insights](https://idataraya.com/insights/) [Payments ArticleJune 24, 2026 The soundbox is the simplest trust upgrade in Malaysian acquiring A soundbox announces each QR payment out loud, so a merchant hears the money land without asking the customer to show a screen. It is the cheapest way to remove a whole category of counter disputes. Read](https://idataraya.com/insights/soundbox-trust-upgrade/) [Operations ArticleNovember 11, 2025 Your terminal estate is a logistics business. Run it like one. Provisioning, key renewals, and app updates across thousands of devices are a distribution problem before they are a technology one. Treat the estate like a fleet and most field visits disappear. Read](https://idataraya.com/insights/provisioning-a-terminal-fleet/) ## Explore More Next Section ### Our Latest Thinking on Payments and Acquiring [Learn more](https://idataraya.com/insights/) Service ### Merchant Acquiring Capability ### Payments and Acceptance --- --- title: "Retail | idataraya" description: "idataraya builds and runs the systems a Malaysian retail chain works in: product, order, customer, inventory, vendor and marketing management, with a POS at the counter and an online store on the same catalogue." url: "https://idataraya.com/industries/retail/" --- # Retail Most retail chains do not lack systems. They have a POS at the counter, a spreadsheet for stock, an email thread with suppliers, a separate storefront someone set up for online orders, and a finance team that spends the start of every month making the four agree. The gap is not any one of those tools. It is that none of them share a catalogue, a stock position, or a customer record, so every question that crosses two of them has to be answered by hand. idataraya builds the system that holds all of it, from the product record through to the counter and the storefront, and then runs it. One catalogue, one stock position, one customer record, read by the counter and the online store alike. Built by the team that stays on to operate it, so the people who designed the reconciliation are the ones fixing it when a supplier changes their delivery format. ## Our Retail Services ### Product management ### Order management ### Customer management ### Inventory management ### Vendor management ### Marketing management ### Reporting management ### POS application ### Online Store ## How idataraya Helps Retail Chains A chain does not usually decide to replace its systems. It reaches a point where the workarounds cost more than the software: stock counted by hand because no one trusts the figure, an online store selling what the counter has already sold, month-end spent proving that four sources of truth are describing the same week. idataraya builds one system underneath all of it, holds the catalogue, stock, customers, and suppliers in one place, puts the counter application and the storefront on top of it, and then stays on to run the result. Expand all One catalogue underneath everything We start with the product record, because every other argument in a retail system traces back to it. Products, variants, barcodes, and pricing are held once, and the counter, the storefront, and the back office all read from that. Getting this right first is what makes the rest of the work possible rather than another integration. The counter keeps trading offline A point of sale that stops when the line drops is not a point of sale. The counter application captures offline and syncs when the connection returns, and it drives the payment terminal over ECR so the cashier keys the amount once. What the counter took is in the same records as everything else the moment it reconnects. Online is a channel, not a second system The storefront runs on the same catalogue, the same prices, and the same stock position as the counter. An order placed online and a sale made at the till arrive in one order book. That is what removes the daily job of keeping two systems agreeing about what is in stock and what it costs. Suppliers in the same system as the stock Purchase orders, goods received notes, and supplier invoices sit against the stock they affect. Receiving a delivery updates the position and leaves the finance team a record to match, so purchasing stops being an email thread that someone transcribes into a spreadsheet later. Integrated where you already have something Where a chain already runs an accounting package, a payment provider, or a logistics partner it trusts, we integrate rather than replace. The scope is the system underneath, not a demand that everything else go with it. What matters is that one catalogue and one stock position sit behind whatever stays. We build it, then we run it After go-live idataraya operates what it delivered: releases, patches, support, and the changes a growing chain needs as it opens outlets and adds channels. The team that designed the reconciliation is the team fixing it when a supplier changes their delivery format, which is the point at which most retail systems quietly stop being maintained. ## What This Changes for the Chain One catalogue instead of four that disagree Products, variants, and pricing stop existing in a POS, a spreadsheet, a storefront, and a supplier email at the same time. Held once and read by every channel, a price change is entered in one place and is correct everywhere it applies, which removes most of what a finance team currently spends month-end proving. One stock position read by the counter and the storefront Counter sales and online orders draw down the same figure rather than two copies synced on a schedule. The storefront cannot sell what the last customer at the till already bought, and stock takes stop being an argument about which system was right. The day closes from one report Sales by outlet, counter, product, and payment method sit alongside stock and purchasing in the same view, reconciled against settlement. Head office sees the whole chain and each franchisee sees only their own outlets, so both read the same figures instead of exchanging exports. One team through go-live and after The system is built and then operated by the same team, so releases, patches, and the changes a growing chain needs come from the people who designed it. There is no handover to a support desk that did not build it and no second vendor to arbitrate between. The Shape of It ### One system underneath the counter, the storefront, and the back office Running retail on separate tools means paying for the gaps between them every month. idataraya holds the catalogue, stock, customers, and suppliers in one system, puts the counter application and the online store on top of it, and stays on to operate the result. [Learn more](https://idataraya.com/contact/) ## Our Products and Solutions for Retail Three asasii products carry a retail operation between them: the counter, the storefront, and the back office both report into. Each is a standard product configured for the chain rather than a one-off build, so what runs here is the same software idataraya maintains everywhere else. [Contact the team](https://idataraya.com/contact/) ### POS ### Online Store ### BSC ## Our Insights on Retail [See more insights](https://idataraya.com/insights/) [Operations ArticleJune 24, 2026 One catalogue, or the argument you have every month Nearly every reconciliation problem in a retail chain traces back to the product record living in more than one place. Fix the catalogue first and most of the month-end work stops being necessary. Read](https://idataraya.com/insights/one-catalogue/) [Systems ArticleNovember 11, 2025 The online store that sells what the counter already sold Two systems sharing a product list but not a stock position will oversell, and no amount of syncing on a schedule fixes it. The channels have to read the same position, not copies of it. Read](https://idataraya.com/insights/online-store-oversell/) ## Explore More Next Section ### The systems a retail chain runs on, and what it costs to keep them apart [Learn more](https://idataraya.com/insights/) Capability ### Business Systems Client Impact ### MyPride, Jabatan Penjara Malaysia --- --- title: "Public Sector | idataraya" description: "idataraya builds and operates the systems public agencies run their services on: enforcement, licensing, counter and kiosk, collections, vendor portals, and document processing with applied AI. Ministry of Finance registered." url: "https://idataraya.com/industries/public-sector/" --- # Public Sector An agency's work reaches the public through its systems. A compound issued in the field, a licence renewed at a counter, an invoice a supplier is waiting on, a stack of applications that arrived faster than officers can key them in. Federal ministries, statutory bodies, local councils, state agencies, district offices, and government-linked companies all run some version of these, and most run them across systems that were procured separately and never made to speak to each other. idataraya builds the software underneath that work, and then operates it under the maintenance terms the contract sets. idataraya is registered with the Ministry of Finance for software system development, maintenance, and data management, and delivers into Malaysian agencies today. The platform deploys into the agency's own data centre or cloud account, so residency and control stay where policy requires them. ## Our Services for the Public Sector ### Enforcement Systems ### Licensing and Permits ### Counter and Kiosk Software ### Revenue Collection ### Billing and Collections ### Vendor and Supplier Portals ### Document Processing with Applied AI ### Agency Online Stores ### Run and Support ## How idataraya Works with Agencies Agencies do not buy software the way companies do. The scope is set in a tender document before a vendor is chosen, the obligations run for years past go-live, and where the data sits is a matter of policy rather than preference. Most of what goes wrong in a government system happens because those three things were treated as paperwork around the build rather than as the shape of it. idataraya scopes against the document, proves the work in a pilot before an agency commits, deploys where policy requires, and staffs the maintenance the contract asks for. Expand all Scoped Against the Tender Document The specification an agency issues is the specification we build to, including the parts about documentation, handover, and support that vendors often price as an afterthought. Where the document asks for something that will not work in practice, we say so during clarification rather than discovering it at user acceptance testing. Proven in a Pilot First Before an agency commits a department to a new system, we run it in one office or one district. That is where we find the parts of the real process that no specification captured, and it is cheaper to find them there than in a rollout across every counter at once. Deployed Where Policy Requires The platform runs in the agency's own data centre or in its cloud accounts, whichever its residency and outsourcing position requires. The deployment target is a configuration of the same product rather than a different one, so choosing to keep data inside the agency does not cost it features. Built for Audit, Not Just for Use Approvals, extractions, and changes to a record are logged with who did them and what they saw, because a public sector system is read by internal audit and by the auditor general as well as by the officer using it. That evidence is produced by the system as it runs, rather than assembled from logs when someone asks. Integrated with What the Agency Already Runs Revenue systems, accounting packages, and identity services stay where they are. We integrate against them rather than asking an agency to replace working systems to accommodate a new one, which is usually the difference between a project that finishes and one that stalls in scope negotiation. We Build It, Then We Run It idataraya operates what it delivers, under the maintenance terms written into the contract. The team that designed the reconciliation is the team answering when a counter cannot close, which is the point at which most government systems quietly stop being maintained. ## What This Changes for the Agency One report closes the day Cash, cheque, card, and QR receipted through the same system and reconciled into the agency's revenue records daily. The finance unit closes from one report rather than balancing each channel by hand and then arguing about the difference. Issued in the field not written in a book Compounds and summonses are raised on a handheld against the offence record, with evidence attached at the point of issue. Supervisors see what was issued and where on the day rather than at the end of the month, and payment reconciles back without a separate return. Self-serve for suppliers and applicants Suppliers submit invoices and track payment themselves, and applicants can see where an application has reached. Both remove a category of phone call that currently occupies officers who have other work, without anyone losing visibility. Exceptions only reach an officer Applied AI reads incoming documents, validates them, and routes only what genuinely needs a decision. An intake backlog stops growing because the volume no longer depends on how fast a person can key it in, and every extraction is recorded for the auditor. The Shape of It ### Registered, delivering, and staying on to operate idataraya is Ministry of Finance registered for software system development, maintenance, and data management, builds into Malaysian agencies today, and operates what it delivers under the terms the contract sets rather than handing over at go-live. [Learn more](https://idataraya.com/contact/) ## Our Products and Solutions for the Public Sector The asasii systems an agency runs its services on. Each is a standard product configured to the agency's process rather than a one-off build, deployed into the agency's own environment, and operated by idataraya after go-live. [Contact the team](https://idataraya.com/contact/) ### Enforcement ### Licensing ### Counter and Kiosk ### Collections ### Vendor Portal ### Document AI ## Our Insights on the Public Sector [See more insights](https://idataraya.com/insights/) [Public sector ArticleJune 24, 2026 What tender documents get wrong about maintenance The build is scoped in detail and the years after it are scoped in a paragraph. That imbalance is why so many agency systems are technically delivered and practically unsupported. Read](https://idataraya.com/insights/tendering-for-maintenance/) [Operations ArticleNovember 11, 2025 Audit evidence is a feature, not a report you run later A public sector system is read by internal audit and the auditor general as well as by the officer using it. Producing that evidence as the system runs is cheaper than assembling it from logs when someone asks. Read](https://idataraya.com/insights/audit-evidence/) ## Explore More Next Section ### The systems an agency runs its services on, and who stays to operate them [Learn more](https://idataraya.com/insights/) Client Impact ### MyPride, Jabatan Penjara Malaysia Capability ### Business Systems --- --- title: "Health Care | idataraya" description: "idataraya builds and operates the administrative systems Malaysian health care providers run on: registration, appointments and queues, billing and deposits, panel and insurer claims, pharmacy, and the counter payments attached to them." url: "https://idataraya.com/industries/health-care/" --- # Health Care The clinical side of a hospital is usually well served. The administrative side around it rarely is. Registration, appointments, deposits, interim bills, guarantee letters, panel claims, pharmacy stock, and the payment at the counter are frequently five or six systems that were bought at different times and never made to agree, so the front desk becomes the integration layer. Hospital groups, clinic chains, pharmacies, diagnostic labs, dental and specialist practices, and dialysis and day-care centres all carry some version of this. idataraya builds the systems underneath that work and then operates them. One patient record behind registration, billing, claims, and the pharmacy counter, so a bill, a deposit, and a guarantee letter refer to the same episode. Built by the team that stays on to run it, and deployed where the provider's data policy requires. ## Our Services for Health Care ### Patient Registration ### Appointments and Queue Management ### Billing and Deposits ### Panel and Insurer Claims ### Pharmacy and Dispensary Systems ### Inventory and Supplier Management ### Counter Payment Acceptance ### Reporting and Reconciliation ### Run and Support ## How idataraya Works with Health Care Providers A hospital or clinic cannot stop trading while its systems are replaced. Patients arrive whether or not the migration went well, and the front desk absorbs whatever does not work. That constraint shapes how this work has to be done: prove it in one site, migrate deliberately, keep the old path available until the new one is trusted, and be present when it goes live rather than reachable by email. idataraya builds the administrative systems around care and stays on to operate them. Expand all One Patient Record Underneath Registration, billing, claims, and the pharmacy counter read one record rather than keeping their own. Nearly every reconciliation argument in a provider's back office traces back to the same patient or the same episode existing in more than one place, so this is the first thing we fix and the thing the rest depends on. Proven at One Site First We run the system at a single clinic, branch, or department before a group commits to it. That is where the parts of the real process that no specification captured surface, and finding them at one front desk is considerably cheaper than finding them at every front desk at once. Built Around Patient Data Obligations Patient data carries obligations that ordinary business data does not. Access is scoped to role, changes to a record are logged with who made them, and the platform deploys into the provider's own data centre or cloud account where its policy requires. The residency position is the provider's decision rather than a condition of the product. Integrated with the Clinical Side Clinical systems stay where they are. We integrate against the systems a provider already runs rather than proposing to replace working clinical software, because the administrative layer is where the pain usually is and replacing more than necessary is how these projects stall. Migrated Without Closing the Counter Outstanding balances, active episodes, and open claims move with the data, and the previous path stays available until the new one is trusted. A provider cannot pause admissions for a cutover, so the plan assumes the counter keeps working throughout. We Build It, Then We Run It idataraya operates what it delivers. The people who designed how deposits net against the final bill are the people answering when a discharge will not close, rather than a support desk reading a runbook someone else wrote. ## What This Changes for the Provider One record behind every counter Registration, billing, the pharmacy, and the claims desk read the same patient and the same episode. A returning patient is found rather than duplicated, which removes the balances that otherwise sit against a record nobody is using. Answered at the desk not after a phone call What has been paid, what a deposit covers, and where a guarantee letter or claim has reached are visible while the patient is still at the counter. The front desk stops being the place where questions are collected to be answered later. Claims that age are visible before they are lost Claims are tracked against the episode they belong to, so finance can see what is queried, short-paid, or simply sitting, in time to act. Ageing claims stop being discovered during a write-off review. The day closes from one report Takings by counter and by method reconcile against settlement and against what was billed, with deposits and outstanding balances in the same view. There is no separate exercise to make the billing system and the payment records agree. The Shape of It ### The administrative half of health care, built and then operated Clinical software is usually well served. The registration, billing, claims, pharmacy, and payment systems around it are where a provider's staff lose their day. idataraya builds that half and stays on to run it. [Learn more](https://idataraya.com/contact/) ## Our Products and Solutions for Health Care The asasii systems a provider runs its administration on. Each is a standard product configured to the provider's process rather than a one-off build, deployed where its data policy requires, and operated by idataraya after go-live. [Contact the team](https://idataraya.com/contact/) ### Registration ### Appointments ### Billing ### Claims ### Pharmacy ### Counter and Kiosk ## Our Insights on Health Care [See more insights](https://idataraya.com/insights/) [Operations ArticleJune 24, 2026 The front desk is not an integration layer When registration, billing, claims, and the pharmacy each keep their own version of a patient, the staff at the counter become the thing holding them together. That cost never appears in a system's business case. Read](https://idataraya.com/insights/front-desk-integration-layer/) [Systems ArticleNovember 11, 2025 Claims do not fail at submission, they fail at follow-up Most of what a provider loses to panel and insurer claims is not rejected outright. It is queried, short-paid, or left sitting until someone notices during a write-off review. Read](https://idataraya.com/insights/claims-follow-up/) ## Explore More Next Section ### The administrative systems a provider runs on, and who stays to operate them [Learn more](https://idataraya.com/insights/) Capability ### Business Systems Industry ### Public Sector --- --- title: "Education | idataraya" description: "idataraya builds and operates the administrative systems Malaysian education institutions run on: student records, admissions, fee billing and instalments, the parent portal, bursar reconciliation, and campus payments." url: "https://idataraya.com/industries/education/" --- # Education An institution's academic side and its administrative side are rarely served equally well. Admissions, student records, fee billing, instalment arrangements, the parent asking where a payment went, the canteen and bookstore taking money at the counter, and a bursar office reconciling all of it at semester close are usually spread across systems bought at different times. Universities, private colleges, international schools, K-12 schools, tuition and enrichment centres, vocational and skills institutes, and the canteens and bookstores on their campuses all carry some version of it. idataraya builds the systems underneath that work and then operates them. One student record behind admissions, billing, the parent portal, and the bursar's ledger, so a fee, an instalment, and a receipt refer to the same student. Built by the team that stays on to run it, through every intake peak rather than up to the first one. ## Our Services for Education ### Student Records ### Admissions and Enrolment ### Fee Billing and Instalments ### Parent and Student Portal ### Bursar Reconciliation ### Campus Cashless Acceptance ### Campus Online Store ### Reporting ### Run and Support ## How idataraya Works with Institutions An education institution's year has a shape, and systems work has to respect it. Intake is the peak the whole administration is judged on, semester close is when finance finds out whether the year's records hold up, and neither can be moved for a migration. So the work is planned around the calendar rather than against it: prove it on one programme or one campus, migrate outside the peak, keep the previous path available until the new one is trusted, and be staffed when intake arrives. Expand all One Student Record Underneath Admissions, billing, the parent portal, and the bursar's ledger read one record rather than each keeping their own. Almost every fee dispute an institution has traces back to the same student existing twice, so this is fixed first and the rest depends on it. Planned Around the Academic Calendar Migration happens between intakes, not during one. Cutover dates are chosen against the institution's own calendar, and the plan assumes admissions and fee collection continue throughout, because they do. Proven on One Campus First We run the system for one programme, one campus, or one intake before the institution commits the whole administration to it. The parts of the real process that no specification captured surface there, at a scale where fixing them is cheap. Built Around Student Data Obligations Student records include minors and their families, and the data carries obligations accordingly. Access is scoped to role, changes to a record are logged with who made them, and the platform deploys into the institution's own environment where its policy requires. Integrated with the Academic Side Learning management and academic systems stay where they are. We integrate against what an institution already runs rather than proposing to replace working academic software, because the administrative layer is where the load usually sits. We Build It, Then We Run It idataraya operates what it delivers. The people who designed how an instalment plan handles a late payment are the people answering during intake week, rather than a support desk working from someone else's notes. ## What This Changes for the Institution Semester close from a report, not a marathon Fees, campus takings, and settlement reconcile daily against what was billed, so closing the term is reading a report rather than matching records for a fortnight. Finance finds problems during the term, when they can still be fixed. One student one balance Admissions, billing, the portal, and the bursar's ledger read the same record. A family sees one figure for what they owe, and the institution stops carrying fees against duplicate records that nobody is working. Instalments that follow up on themselves Plans, due dates, and late-fee rules are applied by the system, with reminders on a schedule rather than when someone gets to it. Officers work the exceptions instead of chasing every balance by hand. Paid at eleven at night not queued at the office Parents settle fees, view statements, and top up campus accounts from the portal, and every payment posts to the ledger the bursar reads. The counter queue at the start of term stops being the only way to pay. The Shape of It ### Built and operated, from first application to final ledger The administrative half of an institution, admissions through student records, fee billing, the parent portal, campus payments, and the bursar's reconciliation, built as one system and then operated by the team that built it. [Learn more](https://idataraya.com/contact/) ## Our Products and Solutions for Education The asasii systems an institution runs its administration on. Each is a standard product configured to the institution's own structure and fee rules rather than a one-off build, deployed where its data policy requires, and operated by idataraya after go-live. [Contact the team](https://idataraya.com/contact/) ### Student Records ### Admissions ### Billing ### Parent Portal ### Campus Pay ### Bursar ## Our Insights on Education [See more insights](https://idataraya.com/insights/) [Operations ArticleJune 24, 2026 Semester close is a systems problem, not a finance problem When fees, campus takings, and settlement live in different places, closing the term becomes an exercise in proving three records describe the same months. The fortnight it costs is a design decision nobody made on purpose. Read](https://idataraya.com/insights/semester-close/) [Systems ArticleNovember 11, 2025 The same student, twice, and the fee nobody is chasing Duplicate student records are where fee arrears quietly go to be forgotten. One record underneath admissions, billing, and the bursar removes the problem rather than reporting on it. Read](https://idataraya.com/insights/duplicate-student-records/) ## Explore More Next Section ### The administrative systems an institution runs on, and who stays to operate them [Learn more](https://idataraya.com/insights/) Capability ### Business Systems Industry ### Public Sector --- --- title: "Travel and Tourism | idataraya" description: "idataraya builds and operates the systems Malaysian hospitality and attraction operators run on: reservations, front desk and folio, outlet point of sale, inventory, supplier management, and consolidated reporting across every property." url: "https://idataraya.com/industries/travel-tourism/" --- # Travel and Tourism A resort group, a hotel, or an attractions operator is several businesses sharing a balance sheet. Rooms, food and beverage, retail, tickets, and events each have their own counter, their own stock, and often their own system, and the group finds out how they performed together some time after the month has ended. Add outlets across properties and a seasonal workforce that turns over every intake, and the reporting becomes an exercise in collecting exports. idataraya builds the systems underneath those outlets and then operates them. One guest record, one stock position, and one set of takings across rooms, outlets, and attractions, consolidated as the day runs rather than at month end. Built by the team that stays on to operate it, through peak season rather than up to it. ## Our Services for Travel and Tourism ### Reservations and Booking ### Front Desk and Folio ### Outlet Point of Sale ### Inventory and Stores ### Supplier and Purchasing ### Guest and Member Records ### Payment Acceptance ### Consolidated Reporting ### Run and Support ## How idataraya Works with Operators Hospitality runs on a seasonal calendar and a workforce that changes with it. A system that requires a week of training is a system that will be half-used by the second intake, and a migration attempted in peak season is a decision an operator only makes once. So the work is shaped around that: prove it in one outlet, train against the real counter, migrate in the shoulder months, and be staffed when the property is full. Expand all One Availability and One Stock Position Reservations, the front desk, and every outlet read the same availability and the same stock rather than each holding a copy. Most of what an operator reconciles at month end exists because those copies drifted apart during the month. Proven in One Outlet First We run the system in a single restaurant, front desk, or ticket counter before a group commits every property to it. The parts of the real operation that no specification captured surface there, during actual service rather than in a workshop. Built for a Workforce That Turns Over Counter software is designed to be learned in a shift, because seasonal hiring means it will be taught again every intake. Where a task is complex, the system carries the complexity rather than the training material. Migrated in the Shoulder Season Cutover is planned against the operator's own calendar, not ours, and the previous path stays available until the new one is trusted. Nobody replaces a property management system the week before a long weekend. Integrated with the Channels You Sell Through Booking channels, payment providers, and accounting packages an operator already uses stay where they are. We integrate against them rather than asking a group to change how it sells in order to change how it records. We Build It, Then We Run It idataraya operates what it delivers. The team that designed how outlet spend posts to a folio is the team answering when a check-out will not close on a Saturday night. ## What This Changes for the Operator One position for availability and stock Reservations, the front desk, and every outlet read the same figures rather than copies synced on a schedule. Double bookings and stock that exists only on paper stop being month-end discoveries. The folio is current not assembled at check-out Room charges, outlet spend, and deposits post to the guest folio as they happen. The desk can answer what a guest owes while the guest is standing there, and departure stops being where the surprises appear. Outlets keep trading when the link drops Point of sale captures offline and syncs on reconnect, so a network fault at a beach bar does not become a cash-only afternoon and a stack of handwritten chits to key in afterwards. The group reads one view during the month Takings, occupancy, outlet performance, and stock consolidate across properties as the days close. Group finance sees how the month is going while it can still act, rather than after it has ended. The Shape of It ### Several businesses, one set of records Rooms, food and beverage, retail, and tickets each have their own counter but share a balance sheet. idataraya builds the systems underneath all of them so the group reads one position, and then operates the result. [Learn more](https://idataraya.com/contact/) ## Our Products and Solutions for Travel and Tourism The asasii systems a hospitality or attractions operator runs on. Each is a standard product configured to the property's own structure rather than a one-off build, and operated by idataraya after go-live. [Contact the team](https://idataraya.com/contact/) ### Reservations ### Front Desk ### Outlet POS ### Inventory ### Purchasing ### Group Reporting ## Our Insights on Travel and Tourism [See more insights](https://idataraya.com/insights/) [Operations ArticleJune 24, 2026 Your outlets are separate businesses sharing one balance sheet Rooms, food and beverage, retail, and tickets each behave differently and are usually measured differently too. Consolidating them after the fact is why a group learns how its month went a fortnight late. Read](https://idataraya.com/insights/outlets-one-balance-sheet/) [Systems ArticleNovember 11, 2025 Seasonal hiring is a software requirement If counter software takes a week to learn, it will be half-learned by the second intake. The complexity belongs in the system, not in the training deck. Read](https://idataraya.com/insights/seasonal-hiring-software/) ## Explore More Next Section ### The systems a hospitality group runs on, and who stays to operate them [Learn more](https://idataraya.com/insights/) Capability ### Business Systems Industry ### Retail --- --- title: "Transportation and Logistics | idataraya" description: "idataraya builds and operates the systems Malaysian logistics operators run on: consignments and orders, dispatch and routing, proof of delivery, cash on delivery collection, hub and depot operations, contractor settlement, and customer tracking." url: "https://idataraya.com/industries/transportation-logistics/" --- # Transportation and Logistics A delivery operation is judged on one question: where is it, and when will it arrive. Answering that reliably means the order, the route, the driver, the proof of delivery, the money collected at the door, and the invoice to the customer all describing the same consignment. Most operators assemble that answer from a dispatch sheet, a driver's phone, a depot whiteboard, and a settlement spreadsheet that catches up days later. idataraya builds the systems underneath the operation and then runs them. One consignment record from order through delivery, settlement, and invoice, visible to the hub, the driver, and the customer at the same time. Built by the team that stays on to operate it, including the part that runs at four in the morning. ## Our Services for Transportation and Logistics ### Order and Consignment Management ### Dispatch and Routing ### Driver Application ### Proof of Delivery ### Cash on Delivery Collection ### Hub and Depot Operations ### Contractor and Haulier Settlement ### Customer Portal and Tracking ### Run and Support ## How idataraya Works with Operators A logistics operation cannot be paused. Parcels arrive whether or not the migration went well, and the depot absorbs whatever does not work. The other constant is coverage: vans go where the signal does not, so anything that assumes connectivity will fail somewhere on the route. We build for both, prove it on one route or one hub, and stay on to run it. Expand all One Consignment Record Underneath Dispatch, the driver application, proof of delivery, collection, settlement, and the customer's tracking page all read one record. Every dispute an operator has about what happened to a parcel exists because those were separate systems that agreed with each other later. Built to Work Out of Coverage The driver application captures deliveries, collections, and proof offline and syncs when the signal returns. Any design that assumes a connection at the door is a design that produces paper at the depot, and paper is where the money goes missing. Proven on One Route First We run it on a single route or a single hub before the operation commits. Real runs surface the cases a specification never lists, the address that does not exist, the customer who pays half, the parcel refused at the door. Cash Handled as a Control Problem Cash on delivery is the point where an operator's exposure is highest. Collection is recorded at the door and reconciled per driver, per run, and per depot, so a shortfall is identified against a run rather than found in a monthly total. Integrated with the Systems Around It Accounting packages, customer systems, and marketplace or e-commerce platforms an operator already sells through stay where they are. We integrate rather than asking an operation to change who it works with in order to change how it records. We Build It, Then We Run It idataraya operates what it delivers, on the operation's own clock. The team that designed the settlement rules is the team answering when the sort cannot start, which is rarely during office hours. ## What This Changes for the Operator One record from booking to settlement The consignment carries its own history: who ordered it, which run took it, what was collected, and what was proven at the door. Disputes are settled by opening it rather than by reconciling three systems after the fact. Collected at the door recorded at the door Cash on delivery is recorded against the consignment at the point of collection, so what a driver owes at the end of a run is already known. Shortfalls surface against a specific run instead of appearing in a monthly total. The run continues out of coverage Deliveries, collections, and proof are captured offline and sync on return. A dead spot costs signal, not a stack of handwritten sheets to key in at the depot that evening. Hauliers paid from the same records Contractor statements are generated from the trip records the operation actually ran on, with rates and deductions held against the contractor. Settlement stops being a negotiation between two versions of the same month. The Shape of It ### One record from the booking to the settlement Dispatch, the driver, proof of delivery, the money collected, and the contractor's statement all describing the same consignment. idataraya builds that and then operates it on the operation's own clock. [Learn more](https://idataraya.com/contact/) ## Our Products and Solutions for Transportation and Logistics The asasii systems a logistics operator runs on. Each is a standard product configured to the operation's own network and rates rather than a one-off build, and operated by idataraya after go-live. [Contact the team](https://idataraya.com/contact/) ### Consignments ### Dispatch ### Driver App ### Collections ### Hub ### Settlement ## Our Insights on Transportation and Logistics [See more insights](https://idataraya.com/insights/) [Operations ArticleJune 24, 2026 Anything that assumes a signal at the door will produce paper at the depot Coverage fails somewhere on every route. If the driver's tool stops working there, the run continues on handwriting, and handwriting is where collections quietly go missing. Read](https://idataraya.com/insights/signal-at-the-door/) [Systems ArticleNovember 11, 2025 Cash on delivery is a control problem before it is a payments problem The exposure is not in accepting the money, it is in knowing which run it belonged to. Recording collection at the door is what turns a monthly shortfall into a same-day question. Read](https://idataraya.com/insights/cash-on-delivery-control/) ## Explore More Next Section ### The systems a logistics operation runs on, and who stays to operate them [Learn more](https://idataraya.com/insights/) Capability ### Business Systems Industry ### Retail --- --- title: "Property Developers | idataraya" description: "idataraya builds and operates the systems Malaysian property developers run on: unit sales and bookings, purchaser records, progressive billing, financing tracking, contractor and consultant management, defect and handover, and property management after vacant possession." url: "https://idataraya.com/industries/property-developers/" --- # Property Developers A development is a long project with a long tail. The sales gallery takes a booking, financing has to be secured, progressive claims are billed against construction milestones, contractors and consultants are certified and paid, defects are raised and closed after vacant possession, and then the building has to be managed for decades. Each stage is usually run on its own system or on nothing, so the purchaser who booked a unit in the gallery becomes a different record in billing, a third in the defect list, and a fourth when service charges begin. idataraya builds the systems that carry a development from booking to building management, and then operates them. One purchaser and one unit record from the booking form through progressive billing, handover, and the service charge that follows. Built by the team that stays on to operate it, which matters when a system has to outlive the project that bought it. ## Our Services for Property Developers ### Sales and Booking ### Purchaser Records ### Progressive Billing ### Financing and Loan Tracking ### Contractor and Consultant Management ### Defect and Handover ### Property and Facility Management ### Purchaser and Resident Portal ### Run and Support ## How idataraya Works with Developers A development runs for years and changes shape as it goes. Phases launch on their own schedules, the entity that sells is often not the entity that manages, and the systems bought for the sales gallery are rarely the ones anyone thought about for the management office. The result is that the purchaser record fragments at exactly the points where continuity matters most: handover, defects, and the first service charge bill. idataraya builds the record once and carries it the whole way. Expand all One Purchaser, One Unit, All the Way The booking, the agreement, progressive billing, the defect list, and the service charge account are the same purchaser and the same unit. Nearly every complaint a developer receives after handover starts with being asked for information the developer already holds somewhere else. Billed Against What Was Certified Progressive claims are raised from the certified construction stage and the schedule the agreement sets. Keeping billing and certification in one place removes the reconciliation that otherwise happens every claim cycle, and the disputes that come with it. Built for the Handover Cliff Vacant possession is where most developers lose control of their own data, because the management office starts from scratch. We plan for that transition from the beginning: defects, warranties, purchaser details, and account balances carry across rather than being re-entered. Phased With the Development A developer does not stop selling to change systems. Phases are brought on as they launch, and an existing phase keeps running on what it has until it is ready to move. The rollout follows the project's own calendar. Integrated With Accounting and Banking The accounting package, the collection accounts, and the banking arrangements a developer already uses stay where they are. We integrate against them so billing and receipts reconcile without asking finance to change how it operates. We Build It, Then We Run It idataraya operates what it delivers, across the life of the development and into building management. A system handed over at completion and left unmaintained is the reason so many management offices are back on spreadsheets within two years. ## What This Changes for the Developer One purchaser from booking to service charge The record created in the sales gallery carries the agreement, the billing, the defects, and the service charge account. Purchasers stop being asked for information the developer already holds, and the management office does not start from an empty database. Claims match what was certified Progressive billing is raised from the certified stage rather than tracked separately alongside it. The reconciliation between what was claimed and what was certified stops being a cycle that happens every claim. Defects have an owner and an age Each defect is assigned to the responsible contractor and tracked to closure, visible by block, by contractor, and by how long it has been open. The defect liability period is managed rather than survived. The building keeps its records after handover Service charges, arrears, facility bookings, and maintenance run on the same system the development was delivered from. Vacant possession stops being the point at which the data is abandoned. The Shape of It ### From the sales gallery to the management office Most developers run one set of systems to sell a development and a different set, or none, to manage the building afterwards. idataraya builds the record once, carries it across handover, and stays on to operate it. [Learn more](https://idataraya.com/contact/) ## Our Products and Solutions for Property Developers The asasii systems a developer runs on, from launch through handover and into building management. Each is a standard product configured to the development's own structure and payment schedule rather than a one-off build, and operated by idataraya after go-live. [Contact the team](https://idataraya.com/contact/) ### Sales ### Purchasers ### Progressive Billing ### Contracts ### Defects ### Building Management ## Our Insights on Property [See more insights](https://idataraya.com/insights/) [Operations ArticleJune 24, 2026 Vacant possession is where developers lose their own data The management office almost always starts from an empty system, re-entering purchasers, warranties, and defects that the developer already held. That handover is a design decision, and it is usually made by not making it. Read](https://idataraya.com/insights/vacant-possession-data/) [Systems ArticleNovember 11, 2025 Progressive billing belongs with certification, not beside it When claims are raised from one record and certified in another, every cycle produces a reconciliation and some of them produce a dispute. Holding both together removes the work rather than speeding it up. Read](https://idataraya.com/insights/progressive-billing-certification/) ## Explore More Next Section ### The systems a development runs on, from launch to building management [Learn more](https://idataraya.com/insights/) Capability ### Business Systems Industry ### Public Sector --- --- title: "Malls and Commercial Property | idataraya" description: "idataraya builds and operates the systems Malaysian mall operators and commercial landlords run on: leases and tenancy, rental and service charge billing, turnover rent, utilities recharge, car park, facilities and maintenance, visitor access, and the tenant portal." url: "https://idataraya.com/industries/commercial-property/" --- # Malls and Commercial Property A mall or an office tower is a landlord, a utility, a car park operator, and a maintenance business at the same time. Leases and renewals sit with one team, rental and service charge billing with another, submeter readings on a clipboard, car park revenue in its own system, work orders in a book at the management office, and tenant sales declarations arriving by email at the end of each month. Every one of those describes the same tenant in the same lot, and almost none of them are connected. idataraya builds the systems a commercial property runs on and then operates them. One tenant and one lot record behind the lease, the billing, the meter, the work order, and the car park. Built by the team that stays on to operate it, which matters for an asset measured in decades rather than project phases. ## Our Services for Malls and Commercial Property ### Lease and Tenancy Management ### Rental and Service Charge Billing ### Turnover Rent ### Utilities Recharge ### Car Park Management ### Facilities and Maintenance ### Visitor and Access Management ### Tenant Portal ### Run and Support ## How idataraya Works with Operators and Landlords A commercial property cannot be taken offline. Tenants trade, cars enter, plant runs, and the management office deals with whatever the systems do not. The other constant is that the asset outlasts the software: a mall bought a leasing system a decade ago, a car park system from someone else, and a maintenance book that never became a system at all. We build for the whole property rather than one department of it, prove it on one asset, and stay on to run it. Expand all One Tenant, One Lot, One Record The lease, the billing, the meter reading, the work order, and the car park allocation all refer to the same tenant in the same lot. Most disputes a management office has, and most of the arrears it cannot explain, exist because those were separate records that were reconciled by hand. Billing Produced From the Lease Rent, service charge, turnover rent, and recharges are calculated from the lease terms rather than from a spreadsheet that someone updates when a lease changes. When a rent review lands, the billing follows it, which is where most billing errors in commercial property come from. Proven on One Asset First We run it at one mall, one tower, or one management office before a portfolio commits. The parts of the real operation that no specification captured surface there: the recharge method nobody documented, the tenancy that was varied by letter, the meter that serves two lots. Integrated With the Systems on Site Barrier systems, access control, building management systems, and the accounting package a landlord already uses stay where they are. We integrate against them rather than proposing to replace working plant to change how it is recorded. Built for Handover Between Managers Managing agents change, and the property should not lose its history when they do. Leases, assets, work order history, and tenant balances live with the property rather than in an outgoing manager's system, which is what makes a transition an administrative event rather than a data loss. We Build It, Then We Run It idataraya operates what it delivers. The team that designed how a submeter apportions to a lot is the team answering when a tenant disputes a recharge, rather than a support desk reading someone else's notes. ## What This Changes for the Operator Billed from the lease not from a spreadsheet Rent, service charge, turnover rent, and recharges are produced from the lease terms themselves. When a review or a variation lands, billing follows it, which removes the most common source of billing error and the credit notes that follow. One tenant record across leasing, billing, and the building The lease, the meter, the work order, and the car park allocation refer to the same tenant in the same lot. Arrears become explainable, and a tenant stops receiving three different answers depending on who they ask. Declarations submitted not chased Tenants file sales declarations through the portal against the thresholds their leases set, and percentage rent is calculated from them. Month end stops being a collection exercise before it can be a billing one. The property keeps its history when the manager changes Leases, assets, maintenance history, and balances live with the property rather than with the managing agent. A change of manager becomes a handover rather than a rebuild from scanned files. The Shape of It ### A landlord, a utility, a car park, and a maintenance business A commercial property is all four at once, usually on four systems that do not know about each other. idataraya builds one record underneath the lease, the billing, the meter, the work order, and the car park, then stays on to operate it. [Learn more](https://idataraya.com/contact/) ## Our Products and Solutions for Malls and Commercial Property The asasii systems a mall or commercial landlord runs on. Each is a standard product configured to the property's own lease structures and recharge methods rather than a one-off build, and operated by idataraya after go-live. [Contact the team](https://idataraya.com/contact/) ### Leases ### Billing ### Utilities ### Car Park ### Facilities ### Tenant Portal ## Our Insights on Commercial Property [See more insights](https://idataraya.com/insights/) [Operations ArticleJune 24, 2026 Billing errors do not start in billing, they start in the lease When rent reviews and variations are recorded in one place and billed from another, the two drift apart quietly and are reconciled by credit note. Producing the bill from the lease removes the gap rather than auditing it. Read](https://idataraya.com/insights/billing-starts-in-the-lease/) [Systems ArticleNovember 11, 2025 The building outlives every system bought for it Leasing, car park, and maintenance are usually bought a decade apart from three vendors, and the management office becomes the integration between them. That cost never appears in any of the three business cases. Read](https://idataraya.com/insights/building-outlives-its-systems/) ## Explore More Next Section ### The systems a commercial property runs on, and who stays to operate them [Learn more](https://idataraya.com/insights/) Industry ### Property Developers Capability ### Business Systems --- --- title: "Strata and Condominium | idataraya" description: "idataraya builds and operates the systems Malaysian strata communities run on: service charge and sinking fund billing, arrears, the resident portal, facility booking, visitor and access management, maintenance work orders, and the records a JMB or management corporation is accountable for." url: "https://idataraya.com/industries/strata-management/" --- # Strata and Condominium A condominium is a community that has to keep books. Service charges and sinking fund contributions are billed per parcel against share units, arrears have to be pursued through a defined process, an annual general meeting has to be convened with the right notice and the right quorum, and a committee of residents is accountable for all of it under the Strata Management Act. Most of that runs on a spreadsheet held by a managing agent, a WhatsApp group, and a logbook at the guardhouse. idataraya builds the systems a strata community runs on and then operates them. One parcel and one owner record behind the billing, the arrears, the facility booking, the access card, and the work order. Built to leave the records with the property rather than with whoever is managing it this year. ## Our Services for Strata Communities ### Service Charge and Sinking Fund Billing ### Arrears and Recovery ### Owner and Tenant Register ### Resident Portal ### Facility Booking ### Visitor and Access Management ### Maintenance and Work Orders ### Meetings and Governance ### Run and Support ## How idataraya Works with JMBs, MCs, and Managing Agents Strata management has two features that shape every system built for it. The people accountable are volunteers who change at each annual general meeting, and the managing agent who holds the records may be replaced by resolution. So a system that lives inside one agent's tooling puts the community's own records at risk every time either changes. idataraya builds for the property, keeps the records with it, and operates the system across whoever is managing this year. Expand all The Records Stay With the Property The register, the billing history, the arrears trail, the asset list, and the maintenance record belong to the community rather than to the managing agent of the day. A change of agent becomes a change of access, not a rebuild from scanned files and a spreadsheet nobody can reconcile. Built Around What the Act Requires Service charge and sinking fund accounted separately, charges computed against share units, voting entitlement derived from the register and arrears status, and the recovery steps recorded as they are taken. These are obligations, so the system produces the evidence as it runs rather than when someone asks for it. Usable by a Volunteer Committee The people reading these reports are residents with day jobs, and they change every year. What a committee needs to see is presented as a position rather than as a query someone has to know how to build, because a system only a treasurer with an accounting background can operate is a system that stops being used. Proven at One Property First We run it at one building before a portfolio or an agent commits. Every community has arrangements that no specification captured: the parcel that was subdivided, the charge that was varied by resolution, the facility with its own rules. Integrated With the Hardware at the Gate Barrier systems, access control, and intercom already installed stay where they are. We integrate against them so a change in the register reaches the gate, rather than proposing to replace working hardware to achieve it. We Build It, Then We Run It idataraya operates what it delivers. A committee that changes annually cannot also carry responsibility for maintaining software, and a managing agent should not be the only party who knows how the billing works. ## What This Changes for the Community Billed from the register against share units Charges are computed per parcel from share units and the cycle the community set, with the sinking fund accounted separately. Statements stop being rebuilt each cycle, and the maintenance account and sinking fund stop being reconciled by hand. Arrears have a trail not just a total Every reminder, arrangement, and escalation step is recorded against the parcel with the date it was taken. A committee deciding what to do next can see what has already been done, and the evidence exists if recovery goes further. The office stops being the counter for everything Statements, payment, facility booking, work requests, and visitor registration move to the portal and the app. The management office handles what genuinely needs a person rather than every routine request in the building. Records survive the handover of committee and agent The register, the billing history, the maintenance record, and the asset list stay with the property. A new committee or a new managing agent inherits the position rather than starting from what the last one chose to hand over. The Shape of It ### The community's records, kept by the community Committees change annually and managing agents change by resolution. idataraya builds the billing, register, arrears, facilities, access, and maintenance as one system that belongs to the property, and stays on to operate it across both. [Learn more](https://idataraya.com/contact/) ## Our Products and Solutions for Strata Communities The asasii systems a strata community runs on. Each is a standard product configured to the community's own share units, charge cycle, and house rules rather than a one-off build, and operated by idataraya after go-live. [Contact the team](https://idataraya.com/contact/) ### Register ### Billing ### Arrears ### Resident Portal ### Access ### Maintenance ## Our Insights on Strata Management [See more insights](https://idataraya.com/insights/) [Governance ArticleJune 24, 2026 Whose records are they when the managing agent changes If the billing history and the register live inside an agent's tooling, a change of agent is a data loss event. The community owns the obligation, so it should own the records. Read](https://idataraya.com/insights/whose-records-managing-agent/) [Operations ArticleNovember 11, 2025 Arrears are a process, and the process needs a trail A total tells a committee how much is owed. What it needs before deciding anything is what has already been sent, agreed, and escalated on each account, with dates. Read](https://idataraya.com/insights/arrears-need-a-trail/) ## Explore More Next Section ### The systems a strata community runs on, and who stays to operate them [Learn more](https://idataraya.com/insights/) Industry ### Property Developers Industry ### Malls and Commercial Property --- --- title: "Payments and Acceptance | idataraya" description: "What idataraya can build and operate in payments: the gateway itself, the software running on payment terminals, acceptance across DuitNow QR, cards and Malaysian e-wallets, and the integrations into acquirers, payment service providers, core banking and the back office." url: "https://idataraya.com/capabilities/payments-and-acceptance/" --- # Payments and Acceptance Payment acceptance looks like one thing to a customer and is a dozen to whoever builds it. A tap has to reach an acquirer, a QR has to be recognised by the right scheme, the terminal has to keep taking money when the network does not, keys have to be injected and rotated, the point of sale has to be told what happened, and a settlement file has to arrive the next morning and agree with what the counter recorded. This is what idataraya is able to build and run across that whole path. We source the devices and write the software that runs on them, and we can build the gateway underneath rather than only integrating with someone else's. Where an acquirer, payment service provider, or core banking system is already in place, we integrate against it rather than asking anyone to replace it. ## What We Build in Payments ### Payment Gateway ### Terminal Software ### Acceptance Across Rails ### Acquirer and PSP Integration ### Core Banking Integration ### Back Office and Finance Integration ### Point of Sale and ECR Integration ### Terminal Management and Key Operations ### Merchant and Branch Onboarding ### Settlement and Reconciliation ## How We Work in Payments Payments has a property that most software does not: the failure modes are public and immediate. A counter that cannot take money has a queue in front of it, and a settlement file that does not agree costs someone a day of their week. That shapes how the work is done rather than just how carefully it is tested. Expand all The Failure Path Is the Design Most of the engineering in payments is not the successful authorisation. It is the timeout with an unknown outcome, the duplicate that must not be charged twice, the reversal that arrives after the shift closed, and the device that lost connectivity mid-transaction. Idempotency, retries, and reconciliation are designed first because they are what the system spends its life doing. Certification Time Is Programme Time Scheme and acquirer certification runs on the certifying party's calendar, not the project's, and no vendor compresses it. We plan around it from the start and say so during scoping, because a plan that treats certification as a formality at the end is a plan that will slip at the end. Offline Is a Requirement, Not an Edge Case Coverage fails at some counters, in some basements, and on some routes, every day. Terminal software captures and stores when it cannot reach the host, then reconciles on return. Anything that assumes a connection produces paper at the counter and a discrepancy the next morning. One Record, Not Three A payment exists in the terminal, at the acquirer, and in the business's own system, and the value is in those three agreeing. We build so that what the counter recorded, what settled, and what the books show reconcile daily rather than at month end when nobody can remember the transaction. Integrate Rather Than Replace Acquirers, payment service providers, core banking, and the point of sale a merchant trusts stay where they are. The scope is the acceptance layer and what connects it, because the projects that stall are usually the ones that asked an organisation to change more than the problem required. We Build It, Then We Run It After go-live idataraya operates the estate and the platform: monitoring, key renewals, application updates, and incident response under commitments written into the engagement. Payments does not have a quiet period during which a handover would be safe. ## What This Capability Changes One flow across every rail QR, card, and wallet payments behave like one transaction at the counter and arrive as one record for finance, rather than three rails with three behaviours and three sets of figures to reconcile. The counter keeps trading when the network does not Terminal software captures offline and reconciles on reconnect. A dead spot costs signal rather than a cash-only afternoon and a stack of handwritten slips to key in afterwards. Keyed once from the sale to the device ECR integration sends the amount from the point of sale to the terminal and returns the result against the order. The most common source of counter error is removed rather than trained around. Settlement agrees the next morning What the counter recorded, what each rail settled, and what the books show are reconciled daily. Discrepancies surface while the transaction is still identifiable, not during a month-end review. The Shape of It ### The gateway, the software on the device, and everything between idataraya can build the acceptance layer itself, write the application that runs on the terminal, and integrate both into the acquirer, payment service provider, and core systems already in place. We source the hardware; the software on it is ours. [Learn more](https://idataraya.com/contact/) ## Our Insights on Payments [See more insights](https://idataraya.com/insights/) [Payments ArticleJune 24, 2026 Settlement files never agree on the first pass Every rail settles on its own schedule and in its own format. Treating reconciliation as a reporting feature rather than a core part of the build is why finance teams still spend mornings on it. Read](https://idataraya.com/insights/settlement-files/) [Engineering ArticleNovember 11, 2025 The timeout with an unknown outcome The hardest transaction in payments is not the one that fails. It is the one where nobody knows whether it succeeded, and the design has to answer that without charging anyone twice. Read](https://idataraya.com/insights/timeout-unknown-outcome/) ## Explore More Capability ### Payment Hardware [Learn more](https://idataraya.com/insights/) Industry ### Financial Institutions Industry ### Retail --- --- title: "Payment Hardware | idataraya" description: "What idataraya can do with payment devices: select and source the hardware, write the software that runs on it, provision and inject keys, deploy across an estate, and operate the fleet under uptime commitments." url: "https://idataraya.com/capabilities/payment-hardware/" --- # Payment Hardware A payment device is the only part of a payment system a customer touches, and the only part that fails in public. It has to boot at counter open, stay connected through the day, keep taking money when the network drops, accept a key rotation without a site visit, and be replaceable within hours when it dies in a branch a flight away. This is what idataraya is able to do across that estate, from choosing the device to running it years later. We source the hardware rather than manufacture it, and we write the software that runs on it. That is the useful distinction: the device is a commodity, and what it does at the counter is not. ## What We Do With Payment Hardware ### Device Selection and Sourcing ### Terminal Software ### Provisioning and Key Injection ### Fleet Management and Monitoring ### Application and Key Updates ### Logistics, Spares and Replacement ### Rollout and Cutover ### Unattended and Embedded Deployment ### Integration and Settlement ## How We Work With Estates Everything difficult about payment hardware happens after the purchase order. Devices are distributed across sites nobody visits often, operated by staff who turn over, and judged entirely on whether the counter is trading. The engineering is in provisioning, updating, monitoring, and replacing at scale, not in the specification of any single unit. Expand all The Mix Is Decided at the Counter We look at how each counter format actually runs at its busiest before proposing anything: where staff move, where a queue forms, where nobody can look at a screen. A chain that issues one device type to every format is paying for the mismatch somewhere. Configured Before It Ships Provisioning, keys, and the application build are done before a device leaves, so installation is plugging it in. Every step deferred to site is a step performed by someone who does not do it often, in front of a queue. Updates Without Field Visits Application builds, configuration, and key rotation are pushed remotely across the estate. The alternative is a schedule of site visits that scales linearly with the number of outlets, which is how device operations quietly becomes a headcount problem. Spares Positioned Before They Are Needed Configured spares sit in each region rather than at head office. The measure that matters is how long a counter is down, and that is decided by where the replacement already is, not by how quickly a ticket is raised. Rollouts Staged, Not Launched Deployment runs by region and format, with each stage proving the one after it. A simultaneous cutover across an estate removes the ability to learn anything before it has already happened everywhere. We Deploy It, Then We Run It After go-live the estate is monitored and maintained by idataraya under commitments written into the engagement. When a soundbox stops announcing payments on a Saturday night, the team that deployed it is the team fixing it. ## What This Capability Changes Trading on the first shift not after a setup visit Devices arrive provisioned, keyed, and tied to the right merchant records. Opening a counter is plugging in a device rather than scheduling someone to configure it in front of a queue. Faults surface first to us, not to the branch The estate is monitored centrally, so a failing device is flagged for swap before it takes a counter cash-only. Head office learns from a console rather than from a phone call. Updated remotely including the keys Application builds, configuration, and key rotation are pushed across the estate without field visits, so device operations stops scaling with the number of outlets. Swapped from nearby not from head office Configured spares are positioned by region and every swap is tracked, so a counter returns to trading while the fault is still an open ticket rather than a courier waiting on a flight. The Shape of It ### The device is sourced, the software on it is ours idataraya does not manufacture terminals. We select and source them, write the application that runs on them, provision and key them, deploy them across an estate, and operate that estate afterwards. [Learn more](https://idataraya.com/contact/) ## Our Insights on Payment Hardware [See more insights](https://idataraya.com/insights/) [Operations ArticleNovember 11, 2025 Your terminal estate is a logistics business. Run it like one. Provisioning, key renewals, and application updates across thousands of devices are a distribution problem before they are a technical one. Treat the estate like a fleet and most field visits disappear. Read](https://idataraya.com/insights/provisioning-a-terminal-fleet/) [Payments ArticleJune 24, 2026 The soundbox is the simplest trust upgrade at a counter A soundbox announces each QR payment out loud, so a merchant hears the money land without asking the customer to show a screen. It is the cheapest way to remove a whole category of counter dispute. Read](https://idataraya.com/insights/soundbox-trust-upgrade/) ## Explore More Capability ### Payments and Acceptance [Learn more](https://idataraya.com/insights/) Capability ### Operations Industry ### Retail --- --- title: "Business Systems | idataraya" description: "What idataraya can build and operate in business systems: custom applications on one record, point of sale and counter software, online stores and portals, workflow and case management, billing and collections, inventory, and the integrations into whatever an organisation already runs." url: "https://idataraya.com/capabilities/business-systems/" --- # Business Systems Most organisations do not lack software. They have a system for sales, another for stock, a storefront someone set up separately, a finance package that predates both, and a set of spreadsheets holding the joins together. Nothing shares a customer, a product, or a stock position, so every question that crosses two systems is answered by a person. This is what idataraya is able to build instead: one system underneath the work, and the channels that read from it. We build custom business applications rather than configuring a package, because the process a client actually runs is rarely the process a package assumes. What we build, we then operate, so the people who designed the reconciliation are the ones maintaining it years later. ## What We Build in Business Systems ### Custom Business Applications ### Master Records and Data Model ### Point of Sale and Counter Software ### Online Stores and Storefronts ### Portals and Self-Service ### Workflow and Case Management ### Billing, Collections and Reconciliation ### Loyalty and Stored Value ### Inventory, Purchasing and Suppliers ### Core System Integration ### Applied AI Inside the Workflow ## How We Build Them Operational systems are used by people who did not choose them, during work they cannot pause, and they are judged on the busiest day rather than the average one. That shapes how the work is done more than any feature list does. Expand all Start From the Job, Not the Feature List We begin with what the person at the counter, the desk, or the depot actually does on a busy day, including the workarounds they have built. The workarounds are the requirements: they are what the current system failed to do, written by the people who had to cope with it. One Record Underneath Everything The customer, product, or account is held once and read by every channel. This is designed before any screen, because a system that keeps its own copy of an entity will drift from the others within a month and spend the rest of its life being reconciled. Proven at One Site Before the Rollout One branch, one outlet, one department. Real use surfaces the parts of the process no specification captured, and finding them once is considerably cheaper than finding them everywhere at once. Migrated Without Stopping the Business Balances, open cases, and history move with the data, and the previous path stays available until the new one is trusted. An organisation cannot pause trading, admissions, or collections for a cutover, so the plan assumes the work continues throughout. Built for the Audit as Well as the User Approvals, changes, and automated decisions are logged with who made them and what they saw. In regulated and public sector work the system is read by auditors as well as operators, and producing that evidence as it runs is cheaper than assembling it on request. We Build It, Then We Run It idataraya operates what it delivers: releases, patches, incident response, and the changes an organisation needs as it grows. A system handed over at go-live and left unmaintained is why so many operations are back on spreadsheets within two years. ## What This Capability Changes One record read by every channel The customer, product, and stock position exist once. Questions that cross two systems stop being answered by a person, and the reconciliation those systems used to require stops being a job. Built to the process not around a package The software follows how the organisation actually works rather than requiring it to reorganise around an assumption. Adoption stops depending on training people out of the way they do their jobs. The counter keeps working when the network does not Front-line software captures offline and syncs on reconnect. A connectivity fault costs signal rather than a day of handwritten records to key in afterwards. Maintained by the builders years after go-live The team that designed the workflow is the team changing it when the process changes. There is no handover to a support desk working from someone else's notes. The Shape of It ### One system underneath the work, and the channels that read from it Counters, storefronts, portals, and back offices reading one record rather than keeping their own. idataraya builds that, integrates it with what an organisation already runs, and stays on to operate it. [Learn more](https://idataraya.com/contact/) ## Our Insights on Business Systems [See more insights](https://idataraya.com/insights/) [Systems ArticleJune 24, 2026 The workarounds are the requirements Every spreadsheet kept alongside a system is a specification someone wrote by hand. Reading them is faster than a workshop and considerably more honest. Read](https://idataraya.com/insights/workarounds-are-requirements/) [Operations ArticleNovember 11, 2025 Two systems, one product list, and the order you cannot fulfil Sharing a catalogue but not a stock position guarantees overselling, and syncing on a schedule only changes how long it takes to find out. Read](https://idataraya.com/insights/online-store-oversell/) ## Explore More Capability ### Artificial Intelligence [Learn more](https://idataraya.com/insights/) Industry ### Retail Client Impact ### MyPride, Jabatan Penjara Malaysia --- --- title: "Payroll and HR Systems | idataraya" description: "What idataraya builds for workforce operations: payroll with Malaysian statutory deductions, leave and claims, time and attendance, employee records and self-service, bank file generation, and the integration into finance." url: "https://idataraya.com/capabilities/payroll-and-hr/" --- # Payroll and HR Systems Payroll is the least forgiving system an organisation runs. It executes on a fixed date whether or not anything else is ready, every person affected checks the output personally, an error is visible to the whole workforce, and the statutory side is not a matter of interpretation. Around it sit leave, claims, shifts, and the employee records all of them depend on, usually in separate systems that disagree by the time the run happens. This is what idataraya builds across that. Payroll, leave, claims, and attendance on one employee record, with Malaysian statutory deductions applied in the run rather than checked afterwards, and a bank file and journals that reconcile before anyone approves them. ## What We Build for Workforce Operations ### Payroll Processing ### Statutory Deductions and Filing ### Employee Records ### Leave Management ### Claims and Expenses ### Time, Attendance and Shifts ### Employee Self-Service ### Bank Files and Disbursement ### Finance Integration ### Run and Support ## How We Build Payroll Systems Payroll has a hard deadline every month and no tolerance for a partial result. That single fact shapes everything: how it is migrated, how it is tested, how it is released, and what happens when something is wrong at four in the afternoon on payday. Expand all Parallel Runs Before Cutover The new system runs alongside the existing one for a full cycle or more, and every difference is explained before anyone switches. A payroll migration is the one case where reconciling to the old system exactly is the objective rather than a compromise. The Statutory Side Is Not Configurable Opinion Contribution ceilings, categories, rounding, and tax tables are implemented as the rules say, and updated when they change. This is the part of payroll where being approximately right is the same as being wrong, and it is checked against the published tables rather than against last month's output. Built Around the Deadline Releases land well clear of the pay date, and there is a defined path for correcting an error after a run has been approved. Payroll cannot be rolled back the way other systems can, so the recovery path is designed rather than improvised. One Employee Record Underneath Leave, claims, attendance, and payroll read the same record. Nearly every payroll dispute traces back to two systems holding a different version of a person's terms, entitlement, or start date. Access and Confidentiality by Design Salary data carries obligations and internal sensitivity that ordinary business data does not. Access is scoped to role, changes are logged, and who can see a figure is a decision made in the design rather than left to a default. We Build It, Then We Run It The system is maintained by the team that built it, including keeping pace with statutory changes. A payroll system that is not maintained becomes a compliance problem quietly, and usually announces itself at year end. ## What This Capability Changes One employee record behind payroll, leave and claims Terms, entitlement, and history exist once. The disputes that come from two systems disagreeing about a start date or an entitlement stop being a monthly occurrence. Statutory in the run not checked afterwards EPF, SOCSO, EIS, and tax deduction are calculated inside the pay run against current tables, with ceilings and rounding applied. Submission files come from the same records rather than being assembled separately. The bank file ties out before approval Payment file and journal are produced from the same run, so what leaves the account and what posts to the ledger agree before anyone signs, rather than being reconciled after payday. A worked shift is paid without re-entry Attendance and rosters feed payroll directly, so overtime and unpaid leave reach the run without being transcribed. The step where most manual payroll errors originate is removed. The Shape of It ### The system with a deadline every month Payroll runs on a fixed date, is checked personally by everyone it touches, and cannot be approximately right on the statutory side. idataraya builds it on one employee record with leave, claims, and attendance, and maintains it as the rates change. [Learn more](https://idataraya.com/contact/) ## Our Insights on Payroll and HR [See more insights](https://idataraya.com/insights/) [Operations ArticleJune 24, 2026 Parallel running is not caution, it is the test A payroll migration is the one case where matching the old system exactly is the goal. Every unexplained difference in a parallel run is a defect you would otherwise find on payday. Read](https://idataraya.com/insights/parallel-running-is-the-test/) [Systems ArticleNovember 11, 2025 Most payroll errors are entered, not calculated The engine rarely computes the wrong figure. It is given the wrong input, because a shift, a leave day, or a change of terms was transcribed between two systems that never spoke. Read](https://idataraya.com/insights/payroll-errors-are-entered/) ## Explore More Capability ### Business Systems [Learn more](https://idataraya.com/insights/) Capability ### Risk Management and Compliance Industry ### Public Sector --- --- title: "Artificial Intelligence | idataraya" description: "What idataraya can build with applied AI: document processing that reads incoming paperwork, copilots and decision support inside the systems people already use, verification and matching, and the audit layer that records what the model did and why." url: "https://idataraya.com/capabilities/artificial-intelligence/" --- # Artificial Intelligence Most organisations do not have an AI problem. They have a queue: forms arriving faster than officers can key them in, invoices waiting on a person to match them, a counter where every question needs someone to look something up. Applied AI is worth building where it removes a step that currently waits on a human, and worth nothing where it produces an answer nobody can check. This is what idataraya is able to build on that basis, inside the systems people already work in. We build applied AI into operational software rather than delivering it as a separate tool. The model reads what arrives, drafts the next step, and records what it did with the inputs it saw, so a supervisor or an auditor can check the decision rather than trust it. ## What We Build With Applied AI ### Document Processing ### Verification and Matching ### Operational Copilots ### Decision Support ### Audit and Governance Layer ### Human Checkpoints and Thresholds ### Model Operations ### Integration and Interfaces ## How We Approach Applied AI The failure mode in this work is not a model that performs badly. It is a model that performs well on a step nobody was waiting on, or one whose output nobody is able to check. Both produce a successful pilot and no operational change. We start from the queue rather than the technology, and we build so the answer can be audited. Expand all Start in the Queue, Not on a Slide We look for where work actually waits: the intake tray, the matching step, the approval that sits until someone opens it. If a step is not the constraint, automating it moves the queue rather than shortening it, however well the model performs. Agree the Checkpoint Before the Build Where a person must still decide, and at what confidence the system may act alone, is settled with the client's risk and operations people before anything is built. Retrofitting a human checkpoint after go-live means rebuilding the workflow around it. Prove It on Real Records Accuracy is measured against the organisation's own documents, including the poor scans, the handwriting, and the formats nobody mentioned. A model evaluated on clean samples tells you very little about the tray it will actually work from. Build Into the System, Not Beside It The assistance appears inside the screen the work already happens in. A separate tool is a second place to look, and in practice it becomes a place nobody looks once the novelty passes. Record What It Did, Not Just What It Decided The input, the output, the confidence, and the human action are logged together. That is what lets a supervisor sample the work, an auditor test it, and the organisation defend a decision months later. We Build It, Then We Run It Accuracy is monitored after go-live, because documents change, processes change, and a model that is not measured is not maintained. idataraya operates what it delivers under the commitments in the engagement. ## What This Capability Changes Exceptions only reach a person Incoming documents are read, validated, and routed, so officers handle what genuinely needs a decision. Intake stops scaling with how fast a person can key, which is what allows a backlog to stop growing. Answered in the screen not in another tool Assistance sits inside the system the work already flows through, drawing on the organisation's own records. There is no second place to look and nothing to remember to open. A reason, not a score for every suggestion Ranking and flagging come with something a person can read and act on. Officers can accept or override with an understanding of why, which is what makes the output usable rather than merely present. Checkable afterwards by a supervisor or an auditor Each extraction and suggestion is recorded with its input, output, and the human action taken. A decision can be defended months later rather than being an assertion about what the system probably did. The Shape of It ### Inside the workflow, and checkable afterwards Applied AI is worth building where it removes a step that waits on a person, and only where the answer can be audited. idataraya builds it into the operational system rather than beside it, and records what it did with what it saw. [Learn more](https://idataraya.com/contact/) ## Our Insights on Applied AI [See more insights](https://idataraya.com/insights/) [Applied AI ArticleJune 24, 2026 Automating a step nobody was waiting on A pilot can be accurate, well received, and change nothing, because the step it improved was not the constraint. Start at the queue and the question answers itself. Read](https://idataraya.com/insights/automating-the-wrong-step/) [Governance ArticleNovember 11, 2025 If nobody can check the answer, it cannot go into production In regulated and public sector work, the audit trail is not paperwork around the model. It is the thing that decides whether the model is allowed to do the job at all. Read](https://idataraya.com/insights/checkable-answers/) ## Explore More Capability ### Business Systems [Learn more](https://idataraya.com/insights/) Industry ### Public Sector Industry ### Financial Institutions --- --- title: "Mobile Applications | idataraya" description: "What idataraya builds on mobile: native Android and iOS, React Native and Flutter, applications for merchants, drivers, field officers and customers, offline capable, integrated with payment terminals and back-office systems, and shipped through the app stores." url: "https://idataraya.com/capabilities/mobile-applications/" --- # Mobile Applications The phone is where a lot of operational work now happens: a merchant checking the day's takings, a driver closing a delivery at a doorstep, an officer issuing a compound in the field, a parent paying a fee at eleven at night. Each of those is a different problem from a consumer app. They run in poor coverage, on cheap devices, in daylight, by people who did not choose the software and cannot stop to troubleshoot it. This is what idataraya builds for that. Native Android and iOS where the device or the performance requires it, React Native or Flutter where one codebase serves both, decided on what the application has to do rather than on preference. Built to work without a network and to integrate with the systems and devices around it. ## What We Build on Mobile ### Native Android and iOS ### Cross-Platform Applications ### Offline First Design ### Field and Operational Applications ### Merchant and Customer Applications ### Device and Peripheral Integration ### Security on the Device ### Release and Store Management ### Run and Support ## How We Build Mobile Operational mobile applications are judged on the worst conditions they meet, not the average ones. Poor coverage, an old device, bright sunlight, gloves, a queue behind the user. Most of what separates an application that gets used from one that gets worked around is decided by taking those conditions seriously at design time. Expand all Designed for the Worst Conditions One hand, outdoors, in a hurry, on a device two generations old. If it only works on a new phone in an office it will be abandoned in the field, and the process it replaced will quietly return. Offline Is Assumed The application is designed to capture without a connection from the beginning rather than having sync added later. Retrofitting offline behaviour means changing every assumption about when data is authoritative. Native or Cross-Platform, Argued We recommend one and explain the trade: what native buys in this specific case, what a shared codebase saves, and what either costs later. The answer differs by application and should not be a house rule. Tested on the Devices People Actually Have Testing runs on the models and OS versions in the client's own fleet, not on the newest hardware. The devices in the field are usually older and more varied than anyone assumes. Release Planned Around Review Store review is outside anyone's control, so releases are scheduled with that in mind and the application can force an update when a version must not remain in use. Payments and compliance changes cannot wait behind a queue. We Build It, Then We Run It Platforms deprecate, OS versions drop out of support, and store requirements change. The team that built the application maintains it, because an unmaintained mobile application stops working through no change of its own. ## What This Capability Changes Work continues out of coverage Deliveries, compounds, and sales are captured offline and reconciled on return. A dead spot costs signal rather than a handwritten record someone has to key in later, badly. Usable in the field not just in a demo Designed for one hand, daylight, and older devices. The application survives contact with the conditions it is actually used in, which is the difference between adoption and a workaround. Keyed once with the device doing the reading Scanners, cameras, and payment terminals feed the application directly, so amounts, codes, and documents are captured rather than retyped in front of a queue. Kept alive as the platforms move OS versions and store requirements change on someone else's schedule. Maintenance is part of the engagement, so an application does not quietly stop working. The Shape of It ### Built for the doorstep, the counter, and the field Operational mobile work happens in bad coverage on ordinary devices, by people with a job to finish. idataraya builds native and cross-platform applications for that, integrated with the systems and hardware around them, and maintains them as the platforms move. [Learn more](https://idataraya.com/contact/) ## Our Insights on Mobile [See more insights](https://idataraya.com/insights/) [Engineering ArticleJune 24, 2026 Anything that assumes a signal will produce paper Coverage fails somewhere on every route and in most basements. If the application stops there, the work continues on handwriting, and that is where records and money go missing. Read](https://idataraya.com/insights/signal-at-the-door/) [Operations ArticleNovember 11, 2025 Test on the phones your staff actually carry Field fleets are older, cheaper, and more varied than any test matrix assumes. The device that struggles is the one deciding whether the rollout succeeds. Read](https://idataraya.com/insights/test-on-real-phones/) ## Explore More Capability ### Business Systems [Learn more](https://idataraya.com/insights/) Capability ### Payment Hardware Industry ### Transportation and Logistics --- --- title: "Digital and Technology | idataraya" description: "What idataraya can engineer between systems: integrations over APIs and host to host connections, API platforms and gateways, pipelines that hold at cut-off, modernisation of systems that cannot be switched off, and the observability to run all of it." url: "https://idataraya.com/capabilities/digital-and-technology/" --- # Digital and Technology Very little of an organisation's difficulty lives inside any one system. It lives between them: the file that arrives late and shifts the close, the field that means one thing in the core system and another in the reporting, the integration that was written once by someone who has left, the interface that cannot be changed because nobody knows what depends on it. This is what idataraya is able to engineer in that space between systems, and then keep running. Integration is the main work in most enterprise programmes, not the part around the edges of it. We build against the systems an organisation already runs and intends to keep, over their APIs, host to host connections, and file transfers, and we stay on to operate what we connect. ## What We Engineer ### System Integration ### API Platform and Gateway ### Data Pipelines and Reconciliation ### Reporting and Data Access ### System Modernisation ### Environments and Release ### Observability and Monitoring ### Data Residency and Deployment ### Run and Support ## How We Work Between Systems Integration work is judged on what happens when something upstream misbehaves, because eventually it will. A file arrives late, a field appears that was not in the specification, a partner changes a format, a network drops mid-transfer. The engineering is in how the system behaves then, not in the happy path that was demonstrated at acceptance. Expand all Read the Real System, Not the Specification We work from what the system actually sends, including the fields the documentation does not mention and the values that appear only at month end. Specifications describe intent; production describes behaviour, and the integration has to survive the second one. Integration Is the Main Work In most programmes it is the largest, slowest, and least visible part, and it is routinely scoped as though it were plumbing. We estimate it as the main body of work and say so during scoping rather than discovering it during delivery. Built for the Late File Pipelines are designed around a source arriving late, partially, or twice, because that is the normal case over a long enough period. Reconciliation proves what was received rather than assuming the run completed correctly. Versioned So Change Stays Local Interfaces are versioned so that a change on one side does not require every consumer to move at the same moment. Without that, every improvement becomes a coordination exercise across teams that do not share a release calendar. Modernised Without a Big Bang Old systems are wrapped and traffic moved deliberately, with the previous path available until the new one has proven itself. The alternative is a cutover weekend that decides several years of work in a few hours. We Build It, Then We Run It Certificates expire, credentials rotate, and counterparties change formats without notice. Whoever operates an integration needs to understand it, which is why the team that built it is the team that keeps it running. ## What This Capability Changes One interface in front of many systems Developers and partners build against a single documented contract instead of negotiating access to each system separately. Adding the next channel becomes configuration rather than another integration programme. The close holds when a file arrives late Pipelines are designed around incomplete and late sources, with reconciliation proving what actually arrived. A delayed upstream file shifts a timestamp rather than producing a report nobody can trust. Change stays local behind versioned interfaces One side can change without every consumer moving at the same time, so improvements stop requiring a coordinated release across teams with different calendars. Noticed by us before it is reported Instrumentation is built in rather than added after the first incident, so failures surface to the people who can fix them and the question of what happened overnight has an answer. The Shape of It ### The work between the systems Most enterprise difficulty is not inside an application, it is in the integrations, pipelines, and interfaces between them. idataraya engineers that layer against what an organisation already runs, and operates it afterwards. [Learn more](https://idataraya.com/contact/) ## Our Insights on Technology and Data [See more insights](https://idataraya.com/insights/) [Data ArticleJune 24, 2026 The warehouse is rarely the problem: where reporting actually breaks Reporting usually fails upstream, in a pipeline that completed against a partial source or a field that means two different things. The dashboard is where you notice, not where it went wrong. Read](https://idataraya.com/insights/where-reporting-breaks/) [Engineering ArticleNovember 11, 2025 Integration is not the plumbing, it is the building It is routinely scoped as the small part around the edges of a programme and routinely turns out to be the largest, slowest part of it. Estimating it honestly changes what a plan is worth. Read](https://idataraya.com/insights/integration-is-the-building/) ## Explore More Capability ### Data and Analytics [Learn more](https://idataraya.com/insights/) Capability ### Cloud and Infrastructure Industry ### Financial Institutions --- --- title: "Data and Analytics | idataraya" description: "What idataraya builds for reporting and analytics: dashboards in Power BI or built into the systems we deliver, the reporting models underneath them, warehouses and marts, scheduled operational reporting, and the data quality work that makes any of it trustworthy." url: "https://idataraya.com/capabilities/data-and-analytics/" --- # Data and Analytics Most organisations are not short of numbers. They are short of numbers everyone agrees with. Sales is counted one way in the point of sale and another in the ledger, two reports use the same word for different things, and the figure that reaches a management meeting arrives late enough that nobody can act on it. Dashboards are the visible part of this work and the smallest part of it. What decides whether they are used is what sits underneath. We build the reporting layer on the systems we deliver and on the systems a client already runs, in Power BI where that is the tool in use, or built directly into the application where the answer belongs next to the work. ## What We Build for Reporting and Analytics ### Dashboards and Visualisation ### Reporting Models and Definitions ### Warehouses and Data Marts ### Ingestion and Transformation ### Embedded Analytics ### Operational and Scheduled Reporting ### Self-Service and Ad Hoc Analysis ### Data Quality and Reconciliation ### Run and Support ## How We Approach Reporting Analytics work fails in a recognisable way. A dashboard is delivered, admired, and then quietly abandoned, because it answered a question nobody was actually asking, or because two people found different numbers in it and stopped trusting both. We start from the decision rather than the data, and we settle the definitions before building anything. Expand all Start From the Decision We ask what someone will do differently once they can see this. A measure that changes no action is a measure worth leaving out, and most abandoned dashboards are full of them. Agree the Definitions First What counts as revenue, an active customer, or a completed order is settled with the people who will argue about it later, and implemented once. Definitions negotiated after a report is live are negotiated with an audience. Prove the Numbers Against the Source New reporting is reconciled against the system of record and against whatever the organisation uses today, and the differences are explained rather than averaged away. A dashboard that disagrees with the ledger will lose, correctly. Built for the Reader, Not the Builder The layout follows how the person actually reads: the exception first, the trend second, the detail on demand. A dense screen is easy to build and expensive to use every morning. Scoped to What Each User May See Row-level access is designed in, so one report serves head office, a branch, and a franchisee without maintaining three versions or leaking anything between them. We Build It, Then We Run It Sources change, definitions evolve, and a model without an owner drifts until nobody trusts it. idataraya maintains the reporting layer as the systems underneath it change. ## What This Capability Changes One definition for each measure Revenue means one thing across every report, implemented once. Meetings stop opening with a discussion about whose number is right before anyone can discuss the number. Read where the work is not in a separate tool Reporting is embedded in the system people already use and scoped to what each user may see, so one report serves head office, a branch, and a franchisee without three versions. Complete, or it says so rather than quietly partial Loads are reconciled and checked, so a report built on a late or partial source is flagged rather than presented as fact. The most damaging reporting failure is the one nobody notices. Still trusted a year later Models and pipelines are maintained as sources change, so the reporting does not decay into a set of dashboards people have privately stopped believing. The Shape of It ### The dashboard is the visible tenth of it What decides whether reporting is used is the model underneath, the definitions everyone agreed, and whether the numbers reconcile to the system of record. idataraya builds all of that, in Power BI or inside the application, and keeps it trustworthy afterwards. [Learn more](https://idataraya.com/contact/) ## Our Insights on Data and Analytics [See more insights](https://idataraya.com/insights/) [Data ArticleJune 24, 2026 The warehouse is rarely the problem: where reporting actually breaks Reporting usually fails upstream, in a load that completed against a partial source or a field that means two different things. The dashboard is where you notice, not where it went wrong. Read](https://idataraya.com/insights/where-reporting-breaks/) [Analytics ArticleNovember 11, 2025 Two people, two numbers, and the end of a dashboard Trust in reporting is lost the first time two colleagues find different answers in it. Settling definitions before building is cheaper than rebuilding credibility afterwards. Read](https://idataraya.com/insights/two-people-two-numbers/) ## Explore More Capability ### Digital, Technology, and Data [Learn more](https://idataraya.com/insights/) Capability ### Business Systems Industry ### Retail --- --- title: "Cloud and Infrastructure | idataraya" description: "What idataraya runs systems on: public cloud, the client's own accounts, or their data centre where policy requires it. Containers and orchestration, environments and deployment pipelines, networking and edge, backup and recovery, cost control, and the monitoring behind all of it." url: "https://idataraya.com/capabilities/cloud-and-infrastructure/" --- # Cloud and Infrastructure Where a system runs decides more than most architecture diagrams admit. It sets what the organisation can promise a regulator about residency, how quickly a release can reach production, what happens at a peak nobody forecast, and what the bill looks like in the third year when nobody is watching. This is what idataraya is able to build and operate underneath the software it delivers. We run in public cloud, in the client's own cloud accounts, or in their data centre, as a configuration of the same system rather than a reduced version of it. Where data must stay is a decision the organisation should be able to make without losing capability for it. ## What We Build and Operate ### Cloud Deployment ### Deployment in the Client's Own Environment ### Containers and Orchestration ### Environments and Deployment Pipelines ### Networking and Edge ### Backup, Recovery and Continuity ### Access and Secrets ### Monitoring, Logging and Alerting ### Cost and Capacity Management ### Run and Support ## How We Approach Infrastructure Infrastructure decisions are hard to reverse and easy to over-build. The failure modes are an architecture that costs more than the problem it solves, and one that cannot meet a residency or availability requirement the organisation has to satisfy. Both come from designing before the constraints are known. Expand all Residency and Policy Decided First Where data may sit, and which processing may happen outside the organisation, is settled with risk and compliance before anything is designed. It determines the shape of the deployment rather than being a setting adjusted inside it. Sized for Real Load Capacity is set against measured behaviour and known peaks rather than a launch estimate. Both over and under provisioning cost money; the difference is that one of them is visible immediately and the other is not. Boring Deployments on Purpose Releases are automated, frequent, and reversible, because rare releases are large ones and large ones fail in ways that are hard to diagnose. The goal is a deployment nobody needs to schedule a meeting for. Instrumented as It Is Built Monitoring, logging, and alerting are built alongside the system rather than added after the first incident. Adding observability to something already carrying traffic is the most expensive time to do it. Recoverable, and Proven So Restores are performed and failures induced in controlled windows. Anything untested is an assumption, and an incident is a poor moment to find out which assumptions were wrong. We Build It, Then We Run It The team that designed the infrastructure operates it, including certificate renewals, patching, and the upgrades nobody schedules until they must. Handing infrastructure to whoever is available is how organisations end up unable to change their own systems. ## What This Capability Changes Runs where policy requires without losing features Public cloud, the organisation's own accounts, or its data centre, as a configuration of the same system. Residency becomes a decision the organisation makes rather than a limit the product imposes. Releases are routine not events Automated deployment with a rollback that works means change ships in small pieces. Small changes fail in ways that are easy to diagnose and easy to reverse. Recoverable, proven not documented and hoped for Restores are exercised and failure induced on purpose, so recovery is something the team has already done rather than a procedure being read for the first time during an incident. Costs stay visible into the third year Spend and utilisation are watched and sized to real load, so the platform bill does not quietly become a line nobody can explain or reduce. The Shape of It ### The same system, wherever policy says it has to run Public cloud, your own accounts, or your data centre. idataraya builds so the deployment target is a configuration rather than a different product, then operates the platform underneath the software it delivered. [Learn more](https://idataraya.com/contact/) ## Our Insights on Infrastructure [See more insights](https://idataraya.com/insights/) [Engineering ArticleJune 24, 2026 Rare releases are large releases A deployment process that needs a meeting produces batched change, and batched change fails in ways nobody can isolate. Making releases boring is a reliability decision, not a convenience one. Read](https://idataraya.com/insights/rare-releases-are-large/) [Operations ArticleNovember 11, 2025 The third-year cloud bill Infrastructure sized at launch and never revisited grows quietly around the edges. By the time anyone asks, nobody remembers what half of it is for. Read](https://idataraya.com/insights/third-year-cloud-bill/) ## Explore More Capability ### Operations [Learn more](https://idataraya.com/insights/) Capability ### Business Resilience Capability ### Security --- --- title: "Security | idataraya" description: "What idataraya builds and operates for security: secure development, authentication and access control, secrets and key management, application and infrastructure hardening, dependency and vulnerability management, logging and detection, and incident response." url: "https://idataraya.com/capabilities/security/" --- # Security Security is not a layer added to a finished system. It is a set of decisions taken while building it: how someone proves who they are, what a compromised credential can reach, where secrets live, what is logged, and what happens when something is wrong at two in the morning. Retrofitting those onto a system already carrying live data is the most expensive version of this work, and the most common. This is what idataraya builds in from the start and operates afterwards. Security work here is engineering rather than assessment. We build authentication, access, and secrets handling into the systems we deliver, harden what runs them, and keep both current as dependencies and threats move. ## What We Build and Operate ### Secure Development ### Authentication and Sessions ### Authorisation and Access Control ### Secrets and Key Management ### Application and Infrastructure Hardening ### Dependency and Vulnerability Management ### Data Protection ### Logging, Monitoring and Detection ### Incident Response ### Run and Support ## How We Approach Security Two things make security expensive: adding it late, and treating it as a document rather than a property of the running system. A policy describes intent, and a policy is what an organisation has when nothing enforces it. We build the control into the system and keep it maintained, because a control that depends on discipline fails during a busy week. Expand all Designed In, Not Assessed Later Authentication, access, and data handling are decided at design. An assessment at the end finds problems at the point where they are most expensive to fix, and usually gets partially deferred as a result. Assume Compromise Somewhere Design so one leaked credential or one compromised component does not reach everything. Least privilege and boundaries limit an incident to something recoverable rather than something disclosed. Controls in the System, Not the Policy A rule that relies on people remembering it will be broken under pressure. Access limits, approvals, and retention are enforced by the software so the control is a property of the system rather than of everyone's discipline. Keep the Blast Radius of Secrets Small Credentials are scoped narrowly, held in a managed store, and rotated routinely. The question we design against is what one leaked key would actually reach, and the answer should be uninteresting. Log Enough to Investigate Security events are recorded with enough context to reconstruct what happened, and retained long enough to be useful. Incidents are frequently discovered weeks later, and the logs decide whether the question can be answered at all. We Build It, Then We Run It Dependencies get vulnerabilities, certificates expire, and access lists drift as people move. Maintenance is where security is actually delivered, and it belongs with the team that understands the system. ## What This Capability Changes Built in not assessed at the end Authentication, access, and data handling are decided at design rather than found in a review when changing them is most expensive. Fewer findings, and the ones that remain are deliberate. One credential does not reach everything Least privilege and real boundaries mean a compromise is contained. The difference between an incident and a disclosure is usually how much a single account could reach. Patched on a cadence not when it makes the news Dependencies are watched and updated routinely, with a path to ship an urgent fix without a release event. Systems stop drifting years behind their own libraries. Answerable afterwards with logs that were kept Security events are recorded with enough context and retained long enough to reconstruct what happened. Incidents found late can still be investigated rather than guessed at. The Shape of It ### A property of the system, not a document about it Security is decided while building: how identity is proven, what a compromise reaches, where secrets live, what is logged. idataraya builds those into the systems it delivers and maintains them as dependencies and threats move. [Learn more](https://idataraya.com/contact/) ## Our Insights on Security [See more insights](https://idataraya.com/insights/) [Engineering ArticleJune 24, 2026 Controls that depend on discipline fail during busy weeks A policy asks people to behave a certain way under pressure. A system that enforces the same rule is the only version of the control that survives the month it matters. Read](https://idataraya.com/insights/controls-that-need-discipline/) [Security ArticleNovember 11, 2025 Account recovery is usually the softest way in Authentication gets the attention and the budget. The reset flow beside it is often the part that decides how hard the system actually is to enter. Read](https://idataraya.com/insights/account-recovery-soft-way-in/) ## Explore More Capability ### Risk Management and Compliance [Learn more](https://idataraya.com/insights/) Capability ### Cloud and Infrastructure Industry ### Financial Institutions --- --- title: "Business Resilience | idataraya" description: "What idataraya can engineer for continuity: offline capable counters, redundancy and standby paths, backup and recovery, monitoring that surfaces a fault before a user reports it, and the testing that proves any of it works." url: "https://idataraya.com/capabilities/business-resilience/" --- # Business Resilience Resilience is not a feature anyone asks for by name. It is asked for after the first bad afternoon: the link that dropped at a counter during a lunch rush, the server that failed on a public holiday, the device that died in a branch a flight away, the report that could not be produced because a file never arrived. What separates an operation that absorbs those from one that stops is decided long before they happen, in how the system was built. This is what idataraya can engineer for that. Continuity is designed into the systems we build rather than sold alongside them. The counter keeps taking money without a network, faults surface to us before a user reports them, and the recovery path is one that has actually been tested rather than documented. ## What We Engineer for Continuity ### Offline Capable Front Ends ### Redundancy and Standby Paths ### Backup and Recovery ### Monitoring and Alerting ### Device and Estate Health ### Degraded Mode Design ### Resilience Testing ### Incident Response and Runbooks ## How We Approach Resilience Resilience work goes wrong in two directions. It is either skipped entirely and discovered during an incident, or applied evenly across everything until it costs more than the outage it prevents. Neither is an engineering position. We decide with the client what genuinely cannot stop, design for that, and are honest about what is accepted risk. Expand all Decide What Cannot Stop Not everything deserves the same protection. Taking money at a counter and closing the day's records usually cannot stop; a management report can wait an afternoon. Naming the difference is what makes the rest of the work affordable. Design for the Failure That Actually Happens In practice it is a dropped link, a dead device, a full disk, an expired certificate, or a counterparty that went down. Elaborate architectures aimed at unlikely events routinely sit alongside systems that a lapsed certificate can stop. Degrade Deliberately What the system does when part of it is unavailable is designed rather than discovered. Continuing to trade in a reduced, well understood mode is almost always worth more to an operation than a faster restoration would be. Test It, Including the Restore Failures are induced in a controlled window and backups are restored to prove they can be. Anything untested is an assumption, and incidents are a poor time to discover which assumptions were wrong. Alert the People Who Can Act Alerting goes to whoever can do something about it, at a volume that keeps it meaningful. The most common failure of monitoring is not absence, it is noise that trained everyone to ignore it. We Build It, Then We Run It idataraya operates what it delivers, which is why the resilience is designed by people who will be the ones woken up. That alignment does more for continuity than any document. ## What This Capability Changes The counter keeps trading without a network Front-end software captures offline and reconciles on reconnect. A dropped link costs signal rather than a cash-only afternoon and a stack of handwritten records to key in afterwards. Faults surface to us before a user reports them Monitoring is built in rather than added after the first incident, so a failing component is being worked on before someone in a branch picks up a phone. Reduced, not stopped when something is unavailable Degraded behaviour is designed rather than improvised, so an operation continues in a known way instead of halting while a component is restored. The restore is proven not assumed Backups are restored and failures induced in controlled windows. Recovery is something the team has done before rather than something written down and hoped for. The Shape of It ### Designed in, and tested on purpose Continuity is a property of how a system was built, not a product bought alongside it. idataraya designs for the failures that actually happen, proves the recovery works, and operates the result. [Learn more](https://idataraya.com/contact/) ## Our Insights on Resilience [See more insights](https://idataraya.com/insights/) [Operations ArticleJune 24, 2026 An untested restore is a belief, not a backup Most organisations discover the gaps in their recovery during the incident that needed it. Restoring on a schedule turns a hope into a control. Read](https://idataraya.com/insights/untested-restore/) [Engineering ArticleNovember 11, 2025 Degrading well beats recovering fast An operation usually needs to keep trading in a reduced way more than it needs a component back in five minutes. Deciding what that reduced way is beforehand is the whole trick. Read](https://idataraya.com/insights/degrading-well/) ## Explore More Capability ### Operations [Learn more](https://idataraya.com/insights/) Capability ### Digital, Technology, and Data Industry ### Financial Institutions --- --- title: "Operations | idataraya" description: "What idataraya does after go-live: monitoring and incident response, support for the people using the system, release and patch management, spares and field swaps, provisioning at scale, and reporting against the commitments in the engagement." url: "https://idataraya.com/capabilities/operations/" --- # Operations Most software is sold on what it does at go-live and judged on what it does for the years afterwards. That gap is where systems quietly stop being maintained: the vendor moved on, the support arrangement was a mailbox, the patch was never applied because nobody owned it, and the organisation ended up running something it could not change. Operations is the capability that closes that gap, and it is the reason idataraya builds what it intends to run. We operate what we deliver. Monitoring, incidents, releases, spares, and provisioning are handled by the team that built the system, under commitments written into the engagement rather than a warranty that expires. ## What We Operate ### Monitoring and Alerting ### Incident Response ### Support for the People Using It ### Release and Patch Management ### Spares, Logistics and Field Swaps ### Provisioning and Onboarding at Scale ### Uptime Commitments and Reporting ### Capacity and Performance ### Documentation and Handover Readiness ## How We Run Systems Operability is decided during the build, not after it. A system that was not instrumented, cannot be released safely, or has no defined behaviour when a dependency fails will be expensive to run no matter who runs it. We design for operation while building, then take responsibility for the result. Expand all Operations Designed Into the Build Instrumentation, health checks, safe release, and rollback are built as the system is built rather than added once it is live. Retrofitting them means changing a system that is already carrying traffic, which is the most expensive time to do it. One Accountable Operator A single team is answerable for whether the system is working, rather than a chain of suppliers each able to point at another. Most operational failures in multi-vendor arrangements are not technical, they are gaps between contracts. Runbooks Held by the People on Call The documented steps belong to the people who would be woken up, and are corrected after every incident that finds them wrong. Documentation nobody has used under pressure is a description of intentions. Controlled Go-Live Launch is staged, with the previous path available and a defined point at which we would roll back. The decision to continue is made against evidence from the running system rather than against a date agreed months earlier. Measured Against What Was Promised Availability and response are reported against the commitments in the engagement, including the months where they were missed. A supplier's own reporting is only worth anything if it shows the bad months too. We Build It, Then We Run It The team that designed the system operates it. That is the whole basis of this capability: the people who know why it works the way it does are the people answering when it does not. ## What This Capability Changes One accountable team not a chain of vendors Whether the system is working is one organisation's responsibility. Nobody spends an outage establishing whose problem it is before anyone starts fixing it. Noticed here first before the branch calls Monitoring surfaces failures to the team that can act, so a fault is being worked before someone in an outlet reports it and while it is still small. Patched on a cadence not when someone remembers Fixes and security patches ship predictably through the organisation's change process, so a system does not drift years behind and become something nobody dares to touch. Measured, including the misses against the commitments Availability and response are reported against what was promised, in months that met it and months that did not. The commitment is checkable rather than asserted. The Shape of It ### The years after go-live are the engagement Software is sold on launch and lived with for years. idataraya designs for operation during the build, then runs the result under commitments that can be measured, with one team accountable for whether it works. [Learn more](https://idataraya.com/contact/) ## Our Insights on Operations [See more insights](https://idataraya.com/insights/) [Public sector ArticleJune 24, 2026 What tender documents get wrong about maintenance The build is specified in detail and the years afterwards in a paragraph. That imbalance is why so many systems are delivered successfully and supported badly. Read](https://idataraya.com/insights/tendering-for-maintenance/) [Operations ArticleNovember 11, 2025 Taking over a system you did not build: the first ninety days Inheriting an operational system is mostly archaeology: what it depends on, what fails routinely, and which parts nobody has dared touch. What you do in the first ninety days decides the next three years. Read](https://idataraya.com/insights/inheriting-a-system/) ## Explore More Capability ### Business Resilience [Learn more](https://idataraya.com/insights/) Capability ### Payment Hardware Industry ### Public Sector --- --- title: "Risk Management and Compliance | idataraya" description: "What idataraya builds for regulated work: append-only audit trails, data residency in the client's own environment, role-based access and segregation of duties, key and secret management, recorded change and incident history, and documentation an examiner or tender panel can read." url: "https://idataraya.com/capabilities/risk-management-and-compliance/" --- # Risk Management and Compliance In regulated work the system has two audiences. The people who use it, and the people who will later ask it to account for itself: internal audit, the auditor general, a regulator, or a tender panel reviewing what a vendor actually delivered. A system built only for the first audience can be perfectly good software and still fail the second, because the evidence was never produced as it ran. This is what idataraya is able to build so that both audiences are served by the same system. Compliance evidence is a property of how the system records its own work, not a report assembled when someone asks. We build the trail as the system runs and deploy into the client's own environment, so residency and control stay where policy requires. ## What We Build for Regulated Work ### Append-Only Audit Trails ### Data Residency and Deployment Control ### Role-Based Access and Segregation of Duties ### Key and Secret Management ### Change and Release Records ### Incident Records ### Backup, Retention and Recovery ### Documentation for Examiners and Panels ### Evidence on Demand ## How We Work in Regulated Environments Compliance requirements arrive as documents, and documents describe outcomes rather than designs. The work is translating them into decisions about access, storage, logging, and change that hold in production, and doing it early enough that they are not retrofitted onto a system that already carries live data. Expand all Discovery With Compliance, Not Only With Operations Risk, compliance, and audit are in the room during design rather than reviewing at the end. The controls they need shape the data model and the access model, and both are expensive to change once a system is live. Controls in the System, Not in the Policy A rule that depends on people remembering it is a rule that will be broken during a busy week. Segregation of duties, retention, and approval limits are enforced by the software so the control is a property of the system rather than of everyone's discipline. Residency Decided Before Architecture Where data may sit, and which processing may happen outside the organisation, is settled with risk and compliance before anything is designed, because it determines the shape of the deployment rather than being a setting within it. Evidence Produced as It Runs The trail is written continuously and can be queried at any point. This is the difference between an audit that samples a running system and an audit that waits while a team assembles what it hopes is the full picture. Integrated Without Weakening the Controls Connecting to core systems, identity services, and third parties is done without creating a shared account that bypasses the access model. The integration path is usually where carefully designed controls quietly acquire an exception. We Build It, Then We Run It The controls are maintained after go-live by the team that designed them, including the parts that decay: certificates, access reviews, and the documentation that drifts as the system changes. ## What This Capability Changes Evidence on demand not assembled on request The trail is produced as the system runs, so an examiner or an internal audit team can be given it rather than waiting while people reconstruct a fortnight of history from logs. Data where policy requires not where the product assumes The platform deploys into the organisation's own data centre or cloud accounts as a configuration of the same product, so residency does not cost the organisation features. Controls that hold during a busy week Segregation of duties, approval limits, and retention are enforced by the system rather than depending on people remembering. The control does not weaken under pressure. Answerable afterwards about what happened and when Change and incident history are recorded as they occur, so the questions a regulator asks about timing and knowledge have answers that were not written after the fact. The Shape of It ### Built for the people who will ask it to account for itself A regulated system serves the officer using it and the examiner reviewing it. idataraya builds the audit trail, the access model, and the change record as the system runs, and deploys where the organisation's policy requires. [Learn more](https://idataraya.com/contact/) ## Our Insights on Risk and Compliance [See more insights](https://idataraya.com/insights/) [Governance ArticleJune 24, 2026 Audit evidence is a feature, not a report you run later If producing the trail takes a project, the system was built for one audience. Writing it as the work happens costs less than assembling it under deadline, every time. Read](https://idataraya.com/insights/audit-evidence/) [Engineering ArticleNovember 11, 2025 Controls that depend on discipline fail during busy weeks A policy asks people to behave a certain way under pressure. A system that enforces the same rule is the only version of the control that survives the month it matters. Read](https://idataraya.com/insights/controls-that-need-discipline/) ## Explore More Industry ### Financial Institutions [Learn more](https://idataraya.com/insights/) Industry ### Public Sector Capability ### Operations --- --- title: "MyPride, Jabatan Penjara Malaysia | idataraya" description: "How idataraya rebuilt the MyPride vocational programme for Jabatan Penjara Malaysia on asasii POS, Online Store, and BSC, with reporting down from a day to under a minute." url: "https://idataraya.com/client-impact/mypride/" --- Client Impact # MyPride moved from a manual workflow to one connected system MyPride, Jabatan Penjara Malaysia MyPride is the vocational products brand of Jabatan Penjara Malaysia. Its sales ran on a manual workflow: orders written down, fulfilment arranged separately, and figures assembled by hand at the end. idataraya rebuilt the operation as one system, from the counter and the online store through to the back office, and connected it to the fulfilment and payment services it depends on. ## Where it started Every part of the process was handled separately. Counter sales, online orders, fulfilment, and payment records each lived in their own place, so nothing could be answered without collecting the pieces first. Producing a report meant working through the day's records by hand, and the answer arrived a day after the question. ## What we built ### asasii POS at the counter Point-of-sale for over-the-counter sales, recording each transaction into the same system the online store and back office read from, so counter takings are part of the record as they happen rather than after a reconciliation. ### asasii Online Store A storefront for direct orders, running on the same catalogue and stock position as the counter. An order placed online and a sale made at the counter arrive in one place instead of two. ### asasii BSC for the back office The administrative layer behind both channels: catalogue, orders, fulfilment status, and reporting. This is where the day is closed and where the reports come from. ## What we connected it to ### Pos Malaysia Orders pass from the system straight to the Pos Malaysia API for despatch, so fulfilment is triggered by the order itself instead of being re-entered into a separate process. ### DuitNow through Public Bank DuitNow acceptance integrated through Public Bank, so payments settle against the same order records the rest of the system works from. ### FPX Online bank transfer through FPX for store purchases, recorded against the order rather than confirmed separately. ### ECR to the payment terminal Electronic cash register integration so the point-of-sale software drives the payment terminal directly. The amount goes to the terminal from the sale, rather than being keyed in a second time where it can be keyed wrong. ## Who it connects to - ![Jabatan Penjara Malaysia](https://idataraya.com/logos/jabatan-penjara-malaysia.svg) - ![Pos Malaysia](https://idataraya.com/logos/pos-malaysia.svg) - ![Public Bank](https://idataraya.com/logos/public-bank.svg) - ![DuitNow](https://idataraya.com/logos/duitnow-qr.svg) - ![FPX](https://idataraya.com/logos/fpx.jpg) - ![Touch 'n Go eWallet](https://idataraya.com/logos/touch-n-go-ewallet.svg) - ![GrabPay](https://idataraya.com/logos/grab.svg) - ![Visa](https://idataraya.com/logos/visa.svg) - ![Mastercard](https://idataraya.com/logos/mastercard.svg) - ![MyDebit](https://idataraya.com/logos/mydebit.png) ## What changed Under a minuteto produce a report that used to take a day One systemfor counter sales, online orders, and the back office Straight to despatchorders reach Pos Malaysia without being re-entered Keyed onceECR sends the amount to the terminal from the sale ## Products used [Contact the team](https://idataraya.com/contact/) ### POS ### Online Store ### BSC ## Explore More Next Section ### See the industries we serve and the capabilities we bring to them, from the counter to the back office. [Learn more](https://idataraya.com/industries/) [Industry Public Sector](https://idataraya.com/industries/public-sector/) [Capability Business Systems](https://idataraya.com/capabilities/business-systems/) --- --- title: "Settlement files never agree on the first pass | idataraya" description: "Every rail settles on its own schedule, in its own format, with its own idea of what a day is. Treating reconciliation as a reporting feature rather than part of the build is why finance teams still spend their mornings on it." url: "https://idataraya.com/insights/settlement-files/" --- Payments # Settlement files never agree on the first pass By Aiman Zulkifli, Priya Raman and Wei Sheng Lim for idataraya Field note 24 June 2026 6 minute read ![A desk with a calculator, a printed financial report and a pen, lit from one side](https://idataraya.com/landing-v2/insights/settlement-files.jpg) ## Key Takeaways Most of what a finance team investigates each morning is not an error. It is the predictable consequence of several payment rails describing the same trading day differently, and it can be designed out. - Card, DuitNow QR, and each e-wallet settle on their own cut-off, cycle, and file format, so one trading day produces several overlapping records that will never match line for line. - The differences that matter, an authorisation never captured, a duplicate after a timeout, an unposted reversal, a fee that does not match the rate, are invisible inside a list of two hundred weekend timing differences. - Reconciliation designed into the build clears the matched items automatically and presents the rest with both records, a reason, and an age. Reconciliation added as a report shows a variance and leaves the work to a person. Every rail settles on its own schedule, in its own format, with its own idea of what a day is. Treating reconciliation as a reporting feature rather than part of the build is why finance teams still spend their mornings on it. A merchant takes a card payment at 11:47pm on Saturday. The terminal records it on Saturday, because that is when it happened. The acquirer settles it on Monday, because Sunday is not a banking day, and reports it in a batch that closed at 10pm Saturday, so the payment falls into Sunday's file. The merchant's finance team opens Monday morning to a Saturday figure that does not match the Saturday takings, and starts looking for an error. There is no error. Nothing has been lost and nothing has been double counted. The counter and the acquirer are describing the same money using two different definitions of when a day ends, and that difference will recur every weekend for as long as the system runs. This is the ordinary condition of payment reconciliation, and it is why the phrase "the files do not agree" is almost never a report of a defect. Most of what a finance team investigates each morning is structural rather than exceptional. ## Every rail has its own clock A merchant accepting card, DuitNow QR, and two or three e-wallets is not accepting payments on one system. Each rail has its own cut-off time, its own settlement cycle, its own file format, and its own behaviour on weekends and public holidays. Some settle net of fees, some settle gross and invoice separately. Some report a refund as a negative transaction on the day it was made, others as a separate entry on the day it cleared. None of that is unreasonable on its own. Taken together it means that the same trading day produces several files that describe overlapping but non-identical sets of transactions, arriving at different times, in different shapes. The work of reconciliation is not addition. It is deciding, transaction by transaction, which record in one file corresponds to which record in another, and then explaining every item that has no counterpart. > The counter is not wrong and the acquirer is not wrong. They are describing the same money using two different definitions of a day. ## Why timing differences look like losses The most common source of an unexplained difference is not a missing payment. It is a payment that exists on both sides but has been assigned to different days. A transaction captured just before a cut-off, a refund processed after one, a reversal that arrives two days later, a payment authorised on one day and captured on the next. Each of these produces a difference on two consecutive days that cancels out across the pair, which means it disappears entirely if anyone ever looks at the week rather than the day. Finance teams rarely get to look at the week, because the daily close has to be signed. So the same handful of timing differences is investigated, individually, every single morning. ## What actually goes wrong Underneath the timing noise there is a smaller set of differences that genuinely matter, and they are the reason this work cannot simply be ignored. A transaction that was authorised but never captured, so the customer saw an approval and the merchant was never paid. A duplicate submission after a timeout, where the terminal did not learn the outcome and the operator tried again. A chargeback or reversal that was never posted back to the merchant's own records. A fee deduction that does not match the agreed rate. A payment collected at a counter that was recorded against the wrong outlet. Each of those is worth finding. None of them is findable if they are sitting in a list of two hundred differences that are mostly weekend timing. ## Reconciliation is not a report The mistake that produces the morning ritual is treating reconciliation as something added after the system works: a report that compares two totals and shows a variance. A total tells you that something is wrong and nothing about where. What a finance team needs is the opposite: matched items cleared automatically and out of sight, and every unmatched item presented with the records from both sides, a reason it did not match, and an age. That requires decisions made during the build rather than afterwards. What identifier ties a transaction to its settled counterpart, and does it survive the round trip through every rail. What the system does with a partial file. Whether a rail's cut-off is modelled explicitly or discovered every weekend. Whether a difference, once explained, stays explained the next day or comes back. None of those are reporting questions. They are design questions, and they are cheap before go-live and expensive afterwards. ## What good looks like The measure worth caring about is not whether the files agree. They will not. It is how much of the difference the system explains without a person. In a system built for this, the overwhelming majority of items match automatically. Known timing differences are recognised as timing differences and shown as such rather than as exceptions. What reaches a person is a short list where each item carries both records, a probable reason, and how long it has been open. The daily close becomes reading that list rather than assembling it. The work does not disappear. Payments are genuinely lost, duplicated, and mispriced, and someone has to notice. But the difference between a finance team that spends twenty minutes a day on reconciliation and one that spends three hours is almost never diligence. It is whether the reconciliation was designed or bolted on. Share Subscribe Get new field notes when we publish them [Enter email](https://idataraya.com/contact/) ## Related content [Capability Payments and Acceptance Read](https://idataraya.com/capabilities/payments-and-acceptance/) [Field note The soundbox is the simplest trust upgrade in Malaysian acquiring Read](https://idataraya.com/insights/soundbox-trust-upgrade/) [Field note The timeout with an unknown outcome Read](https://idataraya.com/insights/timeout-unknown-outcome/) [Field note The workarounds are the requirements Read](https://idataraya.com/insights/workarounds-are-requirements/) [Field note An untested restore is a belief, not a backup Read](https://idataraya.com/insights/untested-restore/) [Field note Anything that assumes a signal at the door will produce paper at the depot Read](https://idataraya.com/insights/signal-at-the-door/) [Field note One catalogue, or the argument you have every month Read](https://idataraya.com/insights/one-catalogue/) [Field note The online store that sells what the counter already sold Read](https://idataraya.com/insights/online-store-oversell/) [Field note What tender documents get wrong about maintenance Read](https://idataraya.com/insights/tendering-for-maintenance/) --- --- title: "The timeout with an unknown outcome | idataraya" description: "The hardest transaction in payments is not the one that fails. It is the one where nobody knows whether it succeeded, and the system has to decide what to do without charging anyone twice." url: "https://idataraya.com/insights/timeout-unknown-outcome/" --- Engineering # The timeout with an unknown outcome By Nurul Hidayah, Daniel Tan and Kavitha Nair for idataraya Field note 9 July 2026 7 minute read ![Network cabling in a dimly lit equipment room](https://idataraya.com/landing-v2/insights/timeout-unknown-outcome.jpg) ## Key Takeaways A request that times out has not failed. It has stopped answering, which is a different thing, and the difference is where duplicate charges and phantom refunds come from. - A timeout tells you the response did not arrive. It says nothing about whether the far side processed the request, and treating the two as the same is the root of most double charges. - Idempotency keys let a retry be recognised as the same attempt rather than a new one. They have to be generated before the first send, by the caller, and survive the process that generated them. - Any transaction whose outcome is unknown needs a reconciliation path that resolves it later without a person guessing. The unknown state is permanent until something goes and asks. The hardest transaction in payments is not the one that fails. It is the one where nobody knows whether it succeeded, and the system has to decide what to do without charging anyone twice. A cashier presses confirm. The terminal sends the authorisation and waits. Eight seconds pass, then twelve, and the connection gives up. The screen shows a failure, the cashier apologises and asks the customer to tap again, and the second attempt succeeds. That evening the customer sees two charges. Nothing in that sequence was a bug in the usual sense. The terminal did what it was told, the acquirer did what it was told, the cashier did the obvious thing. The failure is in the gap between them: the first request may well have been processed, and the terminal had no way to know. ## Three outcomes, two answers Every remote call has three possible outcomes. It succeeded, it failed, or it is unknown. The caller only ever receives two of them, because an unknown outcome is by definition the case where no answer came back. Most software treats the third case as the second. A request that did not respond is marked failed, logged, and forgotten. For a read operation that is harmless. For anything that moves money, creates a record, or triggers a physical action, it is the single most expensive assumption in the system. The discipline is to stop calling it a failure. It is an unknown, and unknowns have to be resolved rather than assumed away. > The system has three possible answers and only ever receives two of them. Everything difficult in payments engineering follows from that. ## Idempotency, and where it usually goes wrong The standard answer is an idempotency key: a value generated by the caller and attached to the request, which the receiver uses to recognise a retry as the same attempt rather than a new one. Send the same key twice and the second call returns the first result instead of doing the work again. The mechanism is well understood. The mistakes are consistent. The key is generated at send time rather than before it, so a retry produces a new key and defeats the point. The key is derived from the payload, so two genuinely separate identical payments collapse into one. The key is held only in memory, so a process restart between attempts loses it. Or the receiver honours the key for a few minutes and the retry arrives an hour later, after a queue drained. The correct shape is dull: generate the key when the intent is formed, persist it with the intent, reuse it for every attempt of that intent, and honour it for longer than any plausible retry window. ## What the counter should do None of this helps the cashier standing in front of a customer. They need an answer in the next few seconds and the system does not have one. The honest design tells them so. Rather than showing a failure, the terminal should say that the result is not yet known, and that they should check before retrying. Where the integration allows, it should perform that check itself: query the transaction by its key, and only offer a retry once it has established the first attempt did not go through. That is slower than showing a red screen, and it is the difference between a queue that waits ten seconds and a customer who is charged twice and calls the bank tomorrow. ## Resolving the ones that stay unknown Some will remain unresolved at the counter. The connection is genuinely down, the shift ends, the device is switched off. Those transactions need somewhere to go. In a system built for this there is a reconciliation path that picks up every unknown and resolves it against the acquirer's own records, automatically, without anyone deciding by hand what probably happened. If the payment went through, the sale is completed and the customer is not charged again. If it did not, the intent is closed. The measure of whether a payments system was engineered or assembled is what it does with the transactions nobody was watching. Most of the difficult work in this field is not making the successful path fast. It is making sure the ambiguous path always ends somewhere. Share Subscribe Get new field notes when we publish them [Enter email](https://idataraya.com/contact/) ## Related content [Capability Payments and Acceptance Read](https://idataraya.com/capabilities/payments-and-acceptance/) [Field note Integration is not the plumbing, it is the building Read](https://idataraya.com/insights/integration-is-the-building/) [Field note Rare releases are large releases Read](https://idataraya.com/insights/rare-releases-are-large/) [Field note The workarounds are the requirements Read](https://idataraya.com/insights/workarounds-are-requirements/) [Field note An untested restore is a belief, not a backup Read](https://idataraya.com/insights/untested-restore/) [Field note Anything that assumes a signal at the door will produce paper at the depot Read](https://idataraya.com/insights/signal-at-the-door/) [Field note One catalogue, or the argument you have every month Read](https://idataraya.com/insights/one-catalogue/) [Field note The online store that sells what the counter already sold Read](https://idataraya.com/insights/online-store-oversell/) [Field note What tender documents get wrong about maintenance Read](https://idataraya.com/insights/tendering-for-maintenance/) --- --- title: "The workarounds are the requirements | idataraya" description: "Every spreadsheet kept alongside a system is a specification someone wrote by hand. Reading them is faster than a workshop and considerably more honest." url: "https://idataraya.com/insights/workarounds-are-requirements/" --- Systems # The workarounds are the requirements By Farah Iskandar and Chong Wei Ming for idataraya Field note 31 July 2026 5 minute read ![A wall of handwritten notes beside a working desk](https://idataraya.com/landing-v2/insights/workarounds-are-requirements.jpg) ## Key Takeaways The gap between what a system does and what the work needs is already documented, in the files people built to cover it. That evidence is more reliable than anything a requirements session produces. - A workaround is a requirement that was not met, written by the person who had to cope with the shortfall. It carries the real edge cases, because it was built from them. - Requirements workshops describe the process as people believe it should run. Shadow spreadsheets and side channels describe how it actually runs, including the parts nobody wants to admit to. - Anything still done by hand after go-live is the specification for the next release, and it is free to collect if someone is looking. Every spreadsheet kept alongside a system is a specification someone wrote by hand. Reading them is faster than a workshop and considerably more honest. Walk into any operations team that has run the same system for a few years and you will find files that are not part of it. A spreadsheet that tracks which orders are actually ready to ship. A shared document of customers who must never be auto-chased. A WhatsApp group where the depot tells the office what really went out. These are usually described as bad practice, and the instinct is to eliminate them. That instinct is right about the destination and wrong about the order of operations, because each of those files is a specification. Somebody identified a gap between what the system does and what the work requires, and closed it themselves, in their own time, without being asked. ## Why they beat a workshop A requirements session produces a description of the process as people believe it should work. It is filtered by seniority, by what someone is willing to say in front of their manager, and by the ordinary human difficulty of describing something you do without thinking. A workaround has none of those filters. It was built under pressure, by the person who suffers when the process fails, and it contains exactly the cases that matter, because those are the ones that forced it into existence. Nobody maintains a spreadsheet for a hypothetical. It is also complete in a way descriptions are not. The columns are the fields that turned out to be necessary. The manual sort order is the priority nobody wrote down. The tab of exceptions is the list of cases the system cannot represent. ## Reading them properly The useful questions are narrow. What triggers someone to open this file. What do they look at first. What happens if it is not updated. Who else reads it, and what do they do with what they find. The answers locate the failure precisely. A file opened every morning before anything else is covering a missing report. A file with a column of pasted notes is covering a missing field. A file that circulates by email is covering a missing permission, because the person who needs the information cannot get it themselves. It is worth asking why each one started. The answer is often a change made years ago that nobody has revisited, and occasionally the workaround has outlived the problem entirely. ## What to do with what you find The point is not to move each spreadsheet into the software as it stands. Some are covering a genuine gap, some encode a rule that was never agreed, and some exist because two teams disagree and this is how the disagreement is managed. But the collection tells you where the current system stops matching the work, and it does so with more accuracy than any interview. Building against it means the first release addresses things people are already spending time on, which is also the fastest route to adoption: you are not asking anyone to change how they work, you are removing a job they never wanted. And the test after go-live is the same one. Whatever is still being done by hand is the specification for the next release. If the files reappear, the system did not close the gap it claimed to. Share Subscribe Get new field notes when we publish them [Enter email](https://idataraya.com/contact/) ## Related content [Capability Business Systems Read](https://idataraya.com/capabilities/business-systems/) [Field note The online store that sells what the counter already sold Read](https://idataraya.com/insights/online-store-oversell/) [Field note The same student, twice, and the fee nobody is chasing Read](https://idataraya.com/insights/duplicate-student-records/) [Field note The building outlives every system bought for it Read](https://idataraya.com/insights/building-outlives-its-systems/) [Field note Most payroll errors are entered, not calculated Read](https://idataraya.com/insights/payroll-errors-are-entered/) [Field note An untested restore is a belief, not a backup Read](https://idataraya.com/insights/untested-restore/) [Field note Anything that assumes a signal at the door will produce paper at the depot Read](https://idataraya.com/insights/signal-at-the-door/) [Field note One catalogue, or the argument you have every month Read](https://idataraya.com/insights/one-catalogue/) [Field note What tender documents get wrong about maintenance Read](https://idataraya.com/insights/tendering-for-maintenance/) --- --- title: "An untested restore is a belief, not a backup | idataraya" description: "Most organisations discover the gaps in their recovery during the incident that needed it. Restoring on a schedule is what turns a hope into a control." url: "https://idataraya.com/insights/untested-restore/" --- Operations # An untested restore is a belief, not a backup By Hafiz Rahman, Selvam Kumar, Lee Mei Chen and Ariff Bakar for idataraya Field note 18 August 2026 6 minute read ![Racked storage equipment in a server room](https://idataraya.com/landing-v2/insights/untested-restore.jpg) ## Key Takeaways Backup success is measured by whether a job completed. Recovery is measured by whether a business can resume. Almost nobody measures the second one until they have to. - A completed backup job proves data was written somewhere. It proves nothing about whether that data can be read back, is internally consistent, or is complete enough to run on. - Recovery time and recovery point should be numbers the business agreed, not values discovered during an outage. Both are meaningless until a restore has actually been performed against them. - Restores fail for dull reasons: a missing encryption key, an untested dependency, a database that restores but will not start, a retention window shorter than the time it takes to notice corruption. Most organisations discover the gaps in their recovery during the incident that needed it. Restoring on a schedule is what turns a hope into a control. Ask an operations team whether they have backups and the answer is yes, with a dashboard to prove it. Ask when someone last restored from them into a working system, and the answer is usually a pause. That pause is the whole subject. A backup job reports success when it has written data somewhere. That is a statement about a write operation. It is not a statement about whether the data can be read back, whether it is internally consistent, whether the thing that reads it still exists, or whether anyone knows the sequence required to bring a service up from it. ## The dull reasons restores fail The failures are rarely dramatic. A database restores but will not start, because the version that wrote it has moved on. The files are encrypted and the key was held in the system that is gone. The application data is present but the object storage holding uploads was never included, so the records exist and every attachment is missing. A dependency nobody documented is unavailable, so the service restores and immediately fails health checks. The restore itself works and takes eleven hours, which nobody knew because nobody had timed it. Or the corruption started three weeks ago and the retention window is fourteen days, so every available copy contains it. None of these are exotic. Each is ordinary, each is findable in an afternoon, and each is typically found instead at the worst possible time. > Every organisation that has lost data had backups. What they did not have was a restore anyone had performed. ## Two numbers the business owns Recovery point is how much data an organisation can afford to lose, measured in time. Recovery time is how long it can afford to be down. Both are business decisions rather than technical ones, and both are frequently set by an engineer guessing on the organisation's behalf. They are worth agreeing explicitly, because they cost money and the difference between them is large. An hour of tolerance and a minute of tolerance are different architectures with different bills. It is entirely reasonable for a business to accept a longer window in exchange for a lower cost. What is not reasonable is nobody having chosen. Once chosen, the numbers become testable. A restore either meets them or it does not, and that is a fact rather than an opinion. ## Rehearsing it A restore rehearsal does not need to be elaborate. Pick a system, restore it into an isolated environment, bring it up, and check that the data is there and the application works against it. Time the whole thing. Write down what was missing and what nobody knew. The first rehearsal in any organisation finds something. It is usually the encryption key, the undocumented dependency, or the realisation that the runbook was written for an architecture two migrations ago. Doing this on a schedule converts backup from an article of faith into a control that has been exercised. It also means that when it is needed for real, the people performing it have done it before, under no pressure, and know roughly how long they are going to be sitting there. ## The question worth asking Every organisation that has lost data had backups. That is the uncomfortable part: the presence of a backup regime is not correlated with recovering successfully, because the regime was measuring the wrong thing. So the question is not whether backups are running. It is when someone last restored from them, how long it took, and what was found. If nobody can answer, the honest description of the current position is that the organisation has copies of its data and does not know whether it can use them. Share Subscribe Get new field notes when we publish them [Enter email](https://idataraya.com/contact/) ## Related content [Capability Business Resilience Read](https://idataraya.com/capabilities/business-resilience/) [Field note One catalogue, or the argument you have every month Read](https://idataraya.com/insights/one-catalogue/) [Field note Your terminal estate is a logistics business. Run it like one. Read](https://idataraya.com/insights/provisioning-a-terminal-fleet/) [Field note Seasonal hiring is a software requirement Read](https://idataraya.com/insights/seasonal-hiring-software/) [Field note Arrears are a process, and the process needs a trail Read](https://idataraya.com/insights/arrears-need-a-trail/) [Field note The third-year cloud bill Read](https://idataraya.com/insights/third-year-cloud-bill/) [Field note Taking over a system you did not build: the first ninety days Read](https://idataraya.com/insights/inheriting-a-system/) [Field note Anything that assumes a signal at the door will produce paper at the depot Read](https://idataraya.com/insights/signal-at-the-door/) [Field note The online store that sells what the counter already sold Read](https://idataraya.com/insights/online-store-oversell/) --- --- title: "Anything that assumes a signal at the door will produce paper at the depot | idataraya" description: "Coverage fails somewhere on every route and in most basements. If the driver's tool stops working there, the run continues on handwriting, and handwriting is where collections quietly go missing." url: "https://idataraya.com/insights/signal-at-the-door/" --- Field operations # Anything that assumes a signal at the door will produce paper at the depot By Zulaikha Omar, Ganesh Pillai and Tan Boon Hock for idataraya Field note 2 September 2026 5 minute read ![A delivery driver carrying a parcel from a van](https://idataraya.com/landing-v2/insights/signal-at-the-door.jpg) ## Key Takeaways Offline capability in field software is not a resilience feature. It is the difference between a record captured at the door and a record reconstructed at the depot from memory. - Coverage gaps are routine rather than exceptional: basements, lift lobbies, industrial estates, rural stretches. A tool that stops there stops daily, not occasionally. - When the application cannot capture, the work does not stop. It moves to paper, and every collection, signature and exception written on paper is re-keyed later by someone who was not there. - Offline has to be designed at the start, because it decides when a record becomes authoritative. Adding it later means revisiting every assumption about who holds the truth. Coverage fails somewhere on every route and in most basements. If the driver's tool stops working there, the run continues on handwriting, and handwriting is where collections quietly go missing. A driver reaches the twelfth stop of a run, in the loading bay of a condominium, three floors below ground. The application will not submit the delivery. They have eighteen more stops and a customer waiting, so they write the details on the manifest and carry on. That evening the depot receives a stack of manifests. Somebody keys them in. Some are legible, some are not, one collection amount is ambiguous, and two stops were never written down at all because the driver was holding a parcel in the other hand. This is presented as a discipline problem. It is a design decision that was made months earlier, by someone who had coverage. ## Where coverage actually fails The places field work happens are not the places networks are strongest. Basement loading bays, lift lobbies, warehouses with steel roofs, industrial estates, the interior of large buildings, stretches of road between towns. Add a device that is three years old and a battery at nineteen percent and the effective coverage is worse than any map suggests. The important point is that this is routine. It is not an edge case that occurs during storms; it happens on most runs, at some stops, every day. Software that treats it as exceptional is treating the normal operating environment as an anomaly. ## Paper is not the fallback, it is the consequence When the application cannot record, the work continues anyway, because a parcel still has to be delivered and money still has to be collected. What stops is the recording. Every item that moves to paper loses something. The timestamp becomes approximate. The proof of delivery becomes a signature nobody can match to a stop. A collection amount becomes a figure written quickly and read by someone else hours later. Exceptions become a note in the margin. This is why cash on delivery discrepancies concentrate in exactly the runs with poor coverage. It is not that those drivers are less careful. It is that the system stopped capturing and a person took over. ## What offline actually requires Offline capability is not a cache. It is a decision about where the authoritative record lives between the moment work happens and the moment it syncs. The application must capture completely without a connection, including the parts that feel like they need a server: sequence numbers, receipt identifiers, validation against the manifest. It must queue durably, so closing the application or a flat battery does not discard the queue. It must sync in an order that survives partial success, so a run that uploads half its stops and loses signal again does not duplicate the first half on the next attempt. And it must be honest on screen about what has and has not reached the depot, because a driver who cannot tell the difference will either re-enter work that already synced or assume something synced that did not. All of that is considerably easier to design at the start than to add afterwards, because it determines when a record becomes true. Retrofitting it means revisiting every assumption about who holds the authoritative version. Share Subscribe Get new field notes when we publish them [Enter email](https://idataraya.com/contact/) ## Related content [Industry Transportation and Logistics Read](https://idataraya.com/industries/transportation-logistics/) [Capability Mobile Applications Read](https://idataraya.com/capabilities/mobile-applications/) [Field note One catalogue, or the argument you have every month Read](https://idataraya.com/insights/one-catalogue/) [Field note The online store that sells what the counter already sold Read](https://idataraya.com/insights/online-store-oversell/) [Field note What tender documents get wrong about maintenance Read](https://idataraya.com/insights/tendering-for-maintenance/) [Field note Audit evidence is a feature, not a report you run later Read](https://idataraya.com/insights/audit-evidence/) [Field note The front desk is not an integration layer Read](https://idataraya.com/insights/front-desk-integration-layer/) [Field note The soundbox is the simplest trust upgrade in Malaysian acquiring Read](https://idataraya.com/insights/soundbox-trust-upgrade/) [Field note Your terminal estate is a logistics business. Run it like one. Read](https://idataraya.com/insights/provisioning-a-terminal-fleet/) --- --- title: "One catalogue, or the argument you have every month | idataraya" description: "Nearly every reconciliation problem in a retail chain traces back to the product record living in more than one place. Fix the catalogue first and most of the month-end work stops being necessary." url: "https://idataraya.com/insights/one-catalogue/" --- Operations # One catalogue, or the argument you have every month By Sharifah Aziz, Marcus Yeo and Devi Krishnan for idataraya Field note 12 September 2026 6 minute read ![Stock shelving in a warehouse aisle](https://idataraya.com/landing-v2/insights/one-catalogue.jpg) ## Key Takeaways A chain rarely has a reporting problem. It has several product records that were once identical and have been drifting apart ever since, and every downstream disagreement follows from that. - The product record is the join. If the point of sale, the storefront, and the accounts each keep their own version, every report that crosses two of them requires a person to reconcile it. - Drift is not caused by carelessness. It is caused by ordinary edits made in one place by people who have no way to make them in the others. - Consolidating the catalogue is unglamorous and usually removes more month-end work than any reporting project attempted on top of the existing mess. Nearly every reconciliation problem in a retail chain traces back to the product record living in more than one place. Fix the catalogue first and most of the month-end work stops being necessary. A finance manager at a chain of fourteen outlets spends the first three days of every month establishing what was sold. Not reading it. Establishing it. The point of sale reports by its own product codes. The online store uses a different set, created when the storefront was set up by an agency four years ago. The accounting package has a third, mapped to the first by a spreadsheet a previous employee maintained. Head office reporting reads whichever of these was most recently exported. Nobody chose this. They chose one product list, then added a storefront, then changed accounting systems, and each decision was sensible on the day it was taken. ## How a catalogue drifts Drift does not come from carelessness. It comes from people doing their jobs in a system that only lets them change one copy. A price rises and is updated at the counter, because that is where it matters immediately. Someone online spots that the description is wrong for one variant and fixes it there. A new size arrives and is added first wherever it is needed first. Two outlets create the same product independently, with slightly different names, because neither could see the other's list. Each of those is correct behaviour by the person doing it. The system offered them one place to make the change, and they made it there. > Nobody decided to keep four product lists. They kept one, then bought a storefront, then changed an accounting package, and inherited three more. ## What it costs downstream The cost surfaces everywhere the records meet. Stock is wrong because two codes describe the same item and each has its own count. A promotion applies online and not at the counter, because the discount was attached to one code. Margin is unreliable because cost sits against one record and revenue lands against another. Then there is the human cost, which is larger and less visible. Somebody becomes the person who knows the mapping. They are consulted whenever a figure looks odd, they maintain the sheet that translates between systems, and the organisation quietly depends on them being available at month end. ## Consolidating without stopping the business The work is dull, which is why it is often skipped in favour of a reporting layer that attempts to reconcile the mess without resolving it. That approach produces a dashboard everyone distrusts within two quarters. Consolidation runs in a defined order. Pick the system that will own the product record, usually the one closest to where products are created rather than where they are sold. Export every list and match them, which surfaces the duplicates, the items that exist in one place only, and the ones that share a code and are not the same thing. Resolve those by hand once, because there is no automated answer to whether two similar records are the same product. Then make the other systems read from the owner rather than hold copies, and close the door behind you: if a product can still be created in two places, the drift resumes the following week. ## What changes afterwards The visible change is that month end shortens, often considerably. The more useful change is that questions become answerable in the moment. What is this line's margin, what is actually in stock, did that promotion work: these stop being requests and become things a manager reads. It also removes the dependency on the person who held the mapping in their head, which most chains do not recognise as a risk until that person is on leave during a stock take. Share Subscribe Get new field notes when we publish them [Enter email](https://idataraya.com/contact/) ## Related content [Industry Retail Read](https://idataraya.com/industries/retail/) [Field note Your terminal estate is a logistics business. Run it like one. Read](https://idataraya.com/insights/provisioning-a-terminal-fleet/) [Field note Seasonal hiring is a software requirement Read](https://idataraya.com/insights/seasonal-hiring-software/) [Field note Arrears are a process, and the process needs a trail Read](https://idataraya.com/insights/arrears-need-a-trail/) [Field note The third-year cloud bill Read](https://idataraya.com/insights/third-year-cloud-bill/) [Field note Taking over a system you did not build: the first ninety days Read](https://idataraya.com/insights/inheriting-a-system/) [Field note An untested restore is a belief, not a backup Read](https://idataraya.com/insights/untested-restore/) [Field note The online store that sells what the counter already sold Read](https://idataraya.com/insights/online-store-oversell/) [Field note What tender documents get wrong about maintenance Read](https://idataraya.com/insights/tendering-for-maintenance/) --- --- title: "The online store that sells what the counter already sold | idataraya" description: "Two systems sharing a product list but not a stock position will oversell, and syncing on a schedule only changes how long it takes to find out." url: "https://idataraya.com/insights/online-store-oversell/" --- Systems # The online store that sells what the counter already sold By Rina Halim and Joshua Chandran for idataraya Field note 26 September 2026 5 minute read ![A laptop showing an online checkout on a work surface](https://idataraya.com/landing-v2/insights/online-store-oversell.jpg) ## Key Takeaways Overselling is not a stock accuracy problem. It is what happens when two channels each hold a copy of a number that only one of them is allowed to be right about. - Sharing a catalogue is not sharing a stock position. Most integrations synchronise products and leave each channel counting separately. - Any sync interval creates a window in which both channels believe the same unit is available. Shortening the interval shrinks the window; it never closes it. - The fix is one authoritative position that both channels draw against at the moment of sale, with reservation rather than after-the-fact reconciliation. Two systems sharing a product list but not a stock position will oversell, and syncing on a schedule only changes how long it takes to find out. A customer buys the last of an item at the counter at 2:14pm. At 2:31pm someone buys the same item online. The store has sold one unit twice, and will find out when it comes to pack the order. The usual explanation is that stock was inaccurate. It was not. Both figures were correct at the moment they were read. They were reading two different copies of the same number. ## The interval is the bug Most storefront integrations synchronise on a schedule. Every fifteen minutes, or five, or one, stock levels are pushed from the point of sale to the store. Between those pushes both systems hold a figure and both believe it. The counter sells and decrements its own copy. The store still shows what it was told at the last sync, and accepts an order against it. Shortening the interval reduces how often this happens without changing whether it can. At one minute you oversell less on a quiet Tuesday and just as reliably during a promotion, which is precisely when it costs the most and when the customer is least forgiving. ## Reservation, not reconciliation The alternative is that one position is authoritative and both channels draw against it at the moment of sale rather than against a copy. When an online order is placed, the unit is reserved against that position immediately, before payment completes. When a counter sale rings through, the same. The reservation is short-lived and released if the order is abandoned. Nothing is decremented on a schedule, because nothing is copied. This is more work than a nightly export, and it is the difference between a system that can run a promotion and one that cannot. ## Where it gets harder Multiple locations complicate the picture, because a unit in one outlet is not necessarily available to an online order. That is a policy question rather than a technical one: which locations fulfil online demand, in what priority, and how much buffer is held back. The system should implement whatever the business decides, and it needs the business to decide. Offline capability at the counter creates a genuine edge. A till that has been selling without a connection has decremented locally and cannot have reserved centrally. The honest answer is a small buffer for the channels that can go offline, sized to actual offline duration rather than to optimism. What does not work is treating either of these as a reason to keep synchronising copies. They are reasons to be explicit about a small, bounded uncertainty, rather than accepting an unbounded one on every product. Share Subscribe Get new field notes when we publish them [Enter email](https://idataraya.com/contact/) ## Related content [Industry Retail Read](https://idataraya.com/industries/retail/) [Capability Business Systems Read](https://idataraya.com/capabilities/business-systems/) [Field note The same student, twice, and the fee nobody is chasing Read](https://idataraya.com/insights/duplicate-student-records/) [Field note The building outlives every system bought for it Read](https://idataraya.com/insights/building-outlives-its-systems/) [Field note Most payroll errors are entered, not calculated Read](https://idataraya.com/insights/payroll-errors-are-entered/) [Field note The workarounds are the requirements Read](https://idataraya.com/insights/workarounds-are-requirements/) [Field note What tender documents get wrong about maintenance Read](https://idataraya.com/insights/tendering-for-maintenance/) [Field note Audit evidence is a feature, not a report you run later Read](https://idataraya.com/insights/audit-evidence/) [Field note The front desk is not an integration layer Read](https://idataraya.com/insights/front-desk-integration-layer/) --- --- title: "What tender documents get wrong about maintenance | idataraya" description: "The build is specified in detail and the years afterwards in a paragraph. That imbalance is why so many agency systems are delivered successfully and supported badly." url: "https://idataraya.com/insights/tendering-for-maintenance/" --- Public sector # What tender documents get wrong about maintenance By Kamarul Bahri, Ismail A. Rahim and Yeoh Su Lin for idataraya Field note 10 October 2026 7 minute read ![A public service counter with a waiting area](https://idataraya.com/landing-v2/insights/tender-maintenance.jpg) ## Key Takeaways A tender specifies the deliverable precisely and the decade of operation vaguely, then awards on price. The result is predictable, and it is not the vendor's fault alone. - Build requirements run to hundreds of clauses; support is often a single paragraph naming a response time and nothing about who is staffed, or what a change costs after go-live. - Unspecified obligations get priced at zero by every bidder who wants to win, so the award goes to whoever assumed the least about the years nobody described. - The clauses that change outcomes are dull: named team continuity, a defined rate for changes, source and documentation handover, and an exit that is testable rather than promised. The build is specified in detail and the years afterwards in a paragraph. That imbalance is why so many agency systems are delivered successfully and supported badly. Read a public sector tender for a system and the proportions are consistent. Functional requirements run for eighty pages. Non-functional requirements add another twenty. Maintenance and support, covering the period from go-live until the system is replaced, occupies a paragraph and a table with a response time in it. The system will be built once and operated for eight years. The document describes the first part exhaustively and the second part barely, and then awards largely on price. ## Why the paragraph is expensive Anything a tender does not describe, bidders price according to what they think they can get away with, because the ones who price it honestly are more expensive and lose. If the document does not say who is staffed after go-live, the winning assumption is nobody in particular. If it does not say what a change costs, the assumption is that changes will be quoted individually, at whatever rate applies then. If it does not say the team must have continuity, the assumption is that whoever is free will handle it. None of that is dishonest. It is a rational response to a specification that left the expensive part undefined, and the agency selected for it by choosing on price. > An obligation nobody described is an obligation every bidder prices at zero, and the lowest bid is the one that assumed the least. ## What actually goes wrong afterwards The pattern is familiar to anyone who has inherited an agency system. It works, and it cannot be changed. A statutory rate moves and the change takes four months and a procurement exercise. The people who built it have moved on and the ones answering the phone are reading a runbook. Documentation exists and describes an earlier version. Nobody can say confidently which environment is authoritative. A small enhancement is quoted at a price that makes the agency decide to live without it, and the workaround becomes permanent. Eventually the system is described internally as legacy, which usually means nobody is willing to touch it, and a replacement is tendered. The new tender has eighty pages of functional requirements and a paragraph on maintenance. ## Clauses that change the outcome The useful ones are unglamorous. Name the team, with a requirement for continuity and a notice period on changes to it. A supplier that must keep the same engineers available behaves differently from one that may rotate anyone through. Fix the rate for changes for the term, with a defined unit. This removes the incentive to quote small enhancements at a price that discourages asking, and it lets an agency plan a budget for evolution rather than treating every change as an exception. Require handover artefacts as deliverables in their own right, tested on acceptance: source, build instructions, environment definitions, architecture, and runbooks that someone outside the build team can follow. If these are not acceptance criteria, they will be produced at the end by whoever is left. Specify an exit that can be exercised. Not a clause promising cooperation, but a defined package the agency can take to another supplier, ideally rehearsed once during the term so both sides know it works. ## What agencies can ask bidders Two questions separate suppliers quickly. Who will be answering in year three, and what happens when a statutory rate changes in the middle of a financial year. The answers reveal whether a bidder has thought about operating the system or only about delivering it. A supplier that intends to run what it builds has concrete answers, because it has done it. One that intends to hand over will describe a process. None of this makes procurement harder. It moves effort from specifying features, which bidders are good at estimating, to specifying obligations, which is where the money actually goes. Share Subscribe Get new field notes when we publish them [Enter email](https://idataraya.com/contact/) ## Related content [Industry Public Sector Read](https://idataraya.com/industries/public-sector/) [Capability Operations Read](https://idataraya.com/capabilities/operations/) [Field note Audit evidence is a feature, not a report you run later Read](https://idataraya.com/insights/audit-evidence/) [Field note The front desk is not an integration layer Read](https://idataraya.com/insights/front-desk-integration-layer/) [Field note The soundbox is the simplest trust upgrade in Malaysian acquiring Read](https://idataraya.com/insights/soundbox-trust-upgrade/) [Field note Your terminal estate is a logistics business. Run it like one. Read](https://idataraya.com/insights/provisioning-a-terminal-fleet/) [Field note Claims do not fail at submission, they fail at follow-up Read](https://idataraya.com/insights/claims-follow-up/) [Field note Semester close is a systems problem, not a finance problem Read](https://idataraya.com/insights/semester-close/) [Field note The same student, twice, and the fee nobody is chasing Read](https://idataraya.com/insights/duplicate-student-records/) --- --- title: "Audit evidence is a feature, not a report you run later | idataraya" description: "If producing the trail takes a project, the system was built for one audience. Writing it as the work happens costs less than assembling it under deadline, every time." url: "https://idataraya.com/insights/audit-evidence/" --- Governance # Audit evidence is a feature, not a report you run later By Norhayati Samad, Vikram Segaran and Chin Kai Wen for idataraya Field note 24 October 2026 6 minute read ![Printed records under close examination](https://idataraya.com/landing-v2/insights/audit-evidence.jpg) ## Key Takeaways A regulated system has two audiences: the person doing the work, and the person who will later ask the system to account for it. Most are built for the first only. - Evidence assembled on request is evidence reconstructed from logs that were never designed to answer the question being asked. - The trail has to record what the user saw at the time, not just what changed, because a decision is judged against the information available when it was made. - An append-only record is the point. If the trail can be edited, it documents the current account of events rather than the events. If producing the trail takes a project, the system was built for one audience. Writing it as the work happens costs less than assembling it under deadline, every time. An examiner asks a straightforward question: on what basis was this application approved, and by whom. In many systems answering this takes a week. Somebody queries the database for the record's current state, which shows the outcome but not the reasoning. Somebody else pulls application logs, which show requests but not what was displayed. A third person finds an email thread. The answer is assembled, plausible, and partly inferred. The system was built to process applications. Nobody built it to explain itself, and explaining itself is now the requirement. ## What a usable trail records The common version records changes: this field went from A to B, at this time, by this user. That is necessary and considerably short of sufficient. A decision is judged against what the decision-maker could see. So the trail needs the inputs as well as the outcome: which documents were attached at the time, what the system had validated, what it flagged, what an automated check returned, and what the officer was shown before they acted. This matters most where automation is involved. If a model extracted a value and an officer accepted it, the useful record is the extraction, the confidence, what was displayed, and the acceptance, as one linked event. Recording only the final value makes the human and the machine indistinguishable afterwards, which is exactly the distinction an examiner is asking about. ## Append-only, and why it is not pedantry If the trail can be modified by the application that writes it, then it describes the current account of what happened rather than what happened. That distinction is invisible day to day and total under scrutiny. Append-only means corrections are added as new entries rather than edits, so the record shows both the original and the correction. It also means the writing path has no delete, and that operational access to the underlying store is separated from the people who use the system. None of this is expensive at design time. All of it is difficult to retrofit onto a system already carrying live data, because the gap covers the period you most need. ## Retention and readability A trail retained for ninety days does not answer a question about last year, and regulated retention periods are usually measured in years. Storage is cheap; the mistake is applying a general log retention policy to records that have a statutory life. Readability matters as much. A trail an engineer must query is one an auditor cannot use, which means every request becomes a ticket. If the people who need the evidence can retrieve it themselves, scoped to what they are entitled to see, the work disappears rather than moving. ## The test The question worth asking of any system handling regulated work is simple: how long would it take to show, for one specific record, everything that happened to it and everything the people involved could see at the time. If the answer is minutes, the evidence is a feature. If it is days, it is a project, and it will be a project every time it is requested. Share Subscribe Get new field notes when we publish them [Enter email](https://idataraya.com/contact/) ## Related content [Industry Public Sector Read](https://idataraya.com/industries/public-sector/) [Capability Risk Management and Compliance Read](https://idataraya.com/capabilities/risk-management-and-compliance/) [Field note Whose records are they when the managing agent changes Read](https://idataraya.com/insights/whose-records-managing-agent/) [Field note If nobody can check the answer, it cannot go into production Read](https://idataraya.com/insights/checkable-answers/) [Field note The front desk is not an integration layer Read](https://idataraya.com/insights/front-desk-integration-layer/) [Field note The soundbox is the simplest trust upgrade in Malaysian acquiring Read](https://idataraya.com/insights/soundbox-trust-upgrade/) [Field note Your terminal estate is a logistics business. Run it like one. Read](https://idataraya.com/insights/provisioning-a-terminal-fleet/) [Field note Claims do not fail at submission, they fail at follow-up Read](https://idataraya.com/insights/claims-follow-up/) [Field note Semester close is a systems problem, not a finance problem Read](https://idataraya.com/insights/semester-close/) --- --- title: "The front desk is not an integration layer | idataraya" description: "When registration, billing, claims and the pharmacy each keep their own version of a patient, the staff at the counter become the thing holding them together. That cost never appears in a business case." url: "https://idataraya.com/insights/front-desk-integration-layer/" --- Health care # The front desk is not an integration layer By Suhaila Mansor, Ravi Thanabalan and Ong Jia Hui for idataraya Field note 7 November 2026 6 minute read ![A reception counter in a clinic](https://idataraya.com/landing-v2/insights/front-desk-integration.jpg) ## Key Takeaways Where systems do not connect, people connect them. In health care administration that work lands on the counter, in front of a patient who is waiting. - A patient existing three times, with three balances, is not a data quality issue. It is the predictable result of three systems each allowed to create a patient. - Manual joining is invisible in every business case because it is performed by staff who were hired for something else and never logged as system cost. - Fixing the identity layer first is what makes the rest tractable; every downstream reconciliation depends on the same patient meaning the same person. When registration, billing, claims and the pharmacy each keep their own version of a patient, the staff at the counter become the thing holding them together. That cost never appears in a business case. A patient arrives for a follow-up. The receptionist searches by name, finds two records, and has to work out which is current. One has the deposit from the last admission, the other has the insurer details. The pharmacy holds a third under a slightly different spelling. She resolves it in about ninety seconds, using knowledge she has accumulated over two years. There is a queue of four people behind. This happens perhaps thirty times a day, and appears in no report anywhere in the organisation. ## Why the counter absorbs it Administrative systems in health care are typically acquired separately and at different times. Registration comes with the clinical package or predates it. Billing arrives with a finance decision. The pharmacy has its own, often chosen by the pharmacist. Claims are handled in a spreadsheet and a portal belonging to each insurer. None of these is unreasonable in isolation, and each was probably a good decision when it was made. What is missing is anything that makes them agree about who a patient is, so the agreement is produced manually at the point where all of them meet, which is the front desk. The staff do it because the alternative is telling a patient to come back, and because nobody has ever framed it as a system problem. It is simply the job. > The integration exists. It is being performed by a person at a counter, with a queue behind them, from memory. ## What it costs, and where it hides The visible cost is time at the counter, which turns into queue length and into complaints that are recorded as service issues rather than systems issues. The invisible costs are larger. Balances sit against records nobody is working, because the receivable is on the duplicate. Claims are submitted against one identity and paid against another, and the difference is investigated at month end. Two patients get merged incorrectly, which is a clinical safety matter rather than an administrative one. And the knowledge concentrates. The person who knows which record is which becomes essential, and the organisation discovers this the week they resign. ## Identity first, then everything else The temptation is to start with the visible pain, usually billing. That is the wrong order, because billing cannot be made correct while the patient it bills is ambiguous. Identity comes first: one record per person, one place where a patient can be created, and a search that surfaces likely duplicates at the point of registration rather than after the fact. Existing duplicates are merged deliberately, with a documented rule and a clinical review where records contain anything clinical. Only then do billing, claims, and pharmacy become tractable, because each is now describing the same person. This ordering is unpopular, since the first phase produces no visible feature. It is also what makes every later phase cheaper than it would otherwise be. ## How you know it worked The measurable outcome is not a dashboard. It is that the receptionist stops resolving identity in front of a queue, that a returning patient is found rather than created, and that questions about what someone owes are answered at the counter rather than referred to accounts. The unmeasured outcome is that the organisation stops depending on one person's memory to know which of three records is real. Share Subscribe Get new field notes when we publish them [Enter email](https://idataraya.com/contact/) ## Related content [Industry Health Care Read](https://idataraya.com/industries/health-care/) [Field note Claims do not fail at submission, they fail at follow-up Read](https://idataraya.com/insights/claims-follow-up/) [Field note The soundbox is the simplest trust upgrade in Malaysian acquiring Read](https://idataraya.com/insights/soundbox-trust-upgrade/) [Field note Your terminal estate is a logistics business. Run it like one. Read](https://idataraya.com/insights/provisioning-a-terminal-fleet/) [Field note Semester close is a systems problem, not a finance problem Read](https://idataraya.com/insights/semester-close/) [Field note The same student, twice, and the fee nobody is chasing Read](https://idataraya.com/insights/duplicate-student-records/) [Field note Your outlets are separate businesses sharing one balance sheet Read](https://idataraya.com/insights/outlets-one-balance-sheet/) [Field note Seasonal hiring is a software requirement Read](https://idataraya.com/insights/seasonal-hiring-software/) [Field note Cash on delivery is a control problem before it is a payments problem Read](https://idataraya.com/insights/cash-on-delivery-control/) --- --- title: "The soundbox is the simplest trust upgrade in Malaysian acquiring | idataraya" description: "A device that says the amount out loud solves a problem no dashboard has ever solved: it tells the person taking the money, at the moment they need to know, without asking them to trust a screen they cannot see." url: "https://idataraya.com/insights/soundbox-trust-upgrade/" --- Payments # The soundbox is the simplest trust upgrade in Malaysian acquiring By Azman Shariff, Low Kian Meng and Sangeetha Raj for idataraya Field note 18 September 2025 5 minute read ![A phone held up to pay by QR code at a counter](https://idataraya.com/landing-v2/insights/soundbox-trust-upgrade.jpg) ## Key Takeaways QR acceptance moved the proof of payment onto the customer's phone, which is the one screen the merchant cannot verify. A soundbox moves it back. - The dispute a soundbox removes is not fraud. It is the ordinary case of a queue, a screenshot, and no way for the person at the till to tell a completed payment from a pending one. - Audio works where a screen does not: hands wet, hands full, eyes on the next customer, stall lit by daylight, operator standing two metres from the counter. - The value is in the confirmation being unprompted and public. Nobody has to ask, and the customer behind hears it too. A device that says the amount out loud solves a problem no dashboard has ever solved: it tells the person taking the money, at the moment they need to know, without asking them to trust a screen they cannot see. Stand behind any busy stall in Malaysia at lunch and watch how a QR payment is actually confirmed. The customer scans, taps, waits, then turns the phone around and holds it up. The person at the till glances at it, sees a green tick and a figure, and waves the next person forward. The whole exchange takes under two seconds and rests entirely on a screen the merchant does not control. Most of the time this is fine, because most people are honest and most payments succeed. The problem is what happens in the small fraction of cases where it is not fine, and how much effort goes into handling them. ## What the merchant is actually looking at A confirmation screen in a wallet app is a rendering, not a receipt. It can be a completed transfer. It can also be a pending one that has not yet cleared, a screenshot from an earlier purchase of the same amount, a transfer to a different recipient entirely, or a successful payment that the merchant has already been shown once by the customer's friend. None of those require sophistication to produce. They require a queue, a hurried operator, and a screen held at arm's length for two seconds. The merchant is not verifying a payment. They are verifying a photograph of a payment, held by the person who benefits from it being believed, under conditions designed for speed rather than scrutiny. > The merchant is not verifying a payment. They are verifying a photograph of a payment, held by the person who benefits from it being believed. ## Why the terminal screen does not fix it The obvious answer is to put the confirmation on the merchant's own device, and for card acceptance that is exactly what happens. For QR it usually does not, because the QR is often a printed sticker with no device behind it at all, and where there is a device, it is frequently not within sight of the person taking the money. Even when it is, a screen demands a specific act: stop, look at this rectangle, read it. That act competes with everything else happening at a counter. Hands are wet at a drinks stall. Hands are full at a bakery. Eyes are on the next order at a nasi campur queue. Outdoor daylight makes a small screen almost unreadable at an angle. A confirmation that requires the operator to stop and look is a confirmation that gets skipped exactly when the counter is busiest, which is when it matters most. ## Sound does not compete for attention A soundbox announces the payment aloud: the amount, and that it was received. That single change moves the confirmation out of the visual channel, which is saturated at a counter, and into the audio channel, which is largely free. The operator does not have to stop. They do not have to look. They do not have to ask the customer for anything. If they hear the amount they expected, the transaction is done, and if they hear nothing, they know to ask before the customer walks away, which is the only moment when asking still works. It also makes the confirmation public. The customer hears it and knows the merchant heard it. The person next in line hears it too. A confirmation nobody can privately fake is a different kind of assurance from one held on a phone. ## What it does not do A soundbox is not a reconciliation tool. It confirms that money arrived at that moment and says nothing about which outlet, which shift, or which product, and it does not remove the need to settle the day against the acquirer's file. It is also not a fraud control in the regulatory sense. It removes a category of ordinary counter dispute, which is a different and much more common problem than deliberate fraud. Treating it as more than that leads to disappointment. Treating it as what it is, a cheap, loud, unambiguous acknowledgement at the exact point of exchange, is why it has spread through Malaysian retail faster than almost anything else in acceptance. Share Subscribe Get new field notes when we publish them [Enter email](https://idataraya.com/contact/) ## Related content [Industry Financial Institutions Read](https://idataraya.com/industries/financial-institutions/) [Capability Payment Hardware Read](https://idataraya.com/capabilities/payment-hardware/) [Field note Settlement files never agree on the first pass Read](https://idataraya.com/insights/settlement-files/) [Field note Your terminal estate is a logistics business. Run it like one. Read](https://idataraya.com/insights/provisioning-a-terminal-fleet/) [Field note Claims do not fail at submission, they fail at follow-up Read](https://idataraya.com/insights/claims-follow-up/) [Field note Semester close is a systems problem, not a finance problem Read](https://idataraya.com/insights/semester-close/) [Field note The same student, twice, and the fee nobody is chasing Read](https://idataraya.com/insights/duplicate-student-records/) [Field note Your outlets are separate businesses sharing one balance sheet Read](https://idataraya.com/insights/outlets-one-balance-sheet/) [Field note Seasonal hiring is a software requirement Read](https://idataraya.com/insights/seasonal-hiring-software/) --- --- title: "Your terminal estate is a logistics business. Run it like one. | idataraya" description: "Provisioning, key renewals and application updates across thousands of devices are a distribution problem wearing a technology costume. The organisations that work this out stop sending people to sites." url: "https://idataraya.com/insights/provisioning-a-terminal-fleet/" --- Operations # Your terminal estate is a logistics business. Run it like one. By Faridah Ibrahim, Tang Wai Keong, Bala Subramaniam and Nik Aisyah for idataraya Field note 2 October 2025 7 minute read ![Electronic devices stored on warehouse shelving](https://idataraya.com/landing-v2/insights/provisioning-a-terminal-fleet.jpg) Provisioning, key renewals and application updates across thousands of devices are a distribution problem wearing a technology costume. The organisations that work this out stop sending people to sites. A bank or payment provider buys terminals as a capital line: unit cost, quantity, warranty. Two years later the number that actually hurts is not on that line at all. It is the running total of site visits. Every visit has a technician, a vehicle, a journey, a merchant who has to be open and available, and a reasonable chance of a second visit because the first one found something unexpected. Multiply by an estate spread from Kangar to Tawau and the arithmetic stops being about devices. The cost of a terminal estate is not the terminals. It is every occasion on which a human being has to be in the same room as one. ## The four reasons someone gets in a van In practice, physical visits to a working terminal come from a short list. A new device needs its initial configuration and merchant parameters. Encryption keys need injecting or renewing. The payment application or its configuration needs updating. Or the device has genuinely failed and needs swapping. Only the last of those is inherently physical. The other three are information being moved, and information does not need a vehicle. That they usually involve one is a decision made at procurement, not a law of nature. > The cost of a terminal estate is not the terminals. It is every occasion on which a human being has to be in the same room as one. ## Key injection is the expensive habit Historically, injecting encryption keys meant a device in a secure room and a person with authority standing next to it. That constraint is real and it is where a lot of estate practice was formed. It is also, for modern hardware, largely solved by remote key loading, where the device and the key management system authenticate each other and the key never exists in the open. Estates that have adopted it treat key renewal as a scheduled background event. Estates that have not treat it as a project, with a window, a roster, and a recall of devices to a depot. The gap between those two operating models is not technology maturity. Both approaches use hardware that supports the modern method. It is whether anyone specified it as a requirement when the estate was bought. ## Updates are a rollout, not a release Pushing a new payment application to thousands of devices is not one action. It is a controlled distribution to a population that is unevenly connected, unevenly powered, and unevenly attended. A terminal in a shopping mall is on mains power and a stable network. A terminal on a night market stall is on battery, on mobile data, and switched off for four days a week. A terminal in a hospital cashier's office is on a network that blocks everything it does not recognise. Any update strategy that assumes a uniform fleet will succeed for most of it and leave a long tail that someone eventually visits. What works is what works in any distribution business: stage the rollout, target by cohort rather than all at once, verify what actually landed rather than what was sent, retry the stragglers automatically, and hold a known-good version to fall back to. None of that is exotic. It is simply the difference between shipping software and shipping software to things you do not physically control. ## You cannot manage what you cannot see The single most common gap in an estate is not a capability, it is a register. Ask an operator how many terminals are deployed, and the answer comes from procurement. Ask how many transacted yesterday, and the answer comes from the switch. The difference between those two numbers is the estate nobody is managing. That difference contains devices sitting in a drawer at a merchant who closed, devices at a merchant who moved and never told anyone, devices returned to a depot and never re-registered, and devices that have quietly stopped working and whose merchant went back to cash without complaining. An estate view that reconciles procurement, deployment, and transaction activity turns all of those from discoveries into a list. ## What running it like logistics means The mental shift is small and the consequences are not. A logistics operator does not ask whether a parcel can be delivered. It asks what the cost per delivery is, which deliveries can be avoided entirely, how to batch what remains, and how to know without asking whether something arrived. Applied to an estate: what is the fully loaded cost of a site visit, which categories of visit can be removed by doing the work remotely, which of the remainder can be combined into one trip, and what tells you the outcome without phoning the merchant. Answer those four and the estate stops being a standing field operation and becomes a system with a small physical tail. The terminals were never the hard part. Share Subscribe Get new field notes when we publish them [Enter email](https://idataraya.com/contact/) ## Related content [Industry Financial Institutions Read](https://idataraya.com/industries/financial-institutions/) [Capability Payment Hardware Read](https://idataraya.com/capabilities/payment-hardware/) [Field note Seasonal hiring is a software requirement Read](https://idataraya.com/insights/seasonal-hiring-software/) [Field note Arrears are a process, and the process needs a trail Read](https://idataraya.com/insights/arrears-need-a-trail/) [Field note The third-year cloud bill Read](https://idataraya.com/insights/third-year-cloud-bill/) [Field note Taking over a system you did not build: the first ninety days Read](https://idataraya.com/insights/inheriting-a-system/) [Field note An untested restore is a belief, not a backup Read](https://idataraya.com/insights/untested-restore/) [Field note One catalogue, or the argument you have every month Read](https://idataraya.com/insights/one-catalogue/) [Field note Claims do not fail at submission, they fail at follow-up Read](https://idataraya.com/insights/claims-follow-up/) --- --- title: "Claims do not fail at submission, they fail at follow-up | idataraya" description: "Most of what a provider loses to panel and insurer claims is never rejected. It is queried, short-paid, or left sitting until someone notices it during a write-off review months later." url: "https://idataraya.com/insights/claims-follow-up/" --- Health care # Claims do not fail at submission, they fail at follow-up By Rosnah Yusof, Lim Sze Ying and Prakash Menon for idataraya Field note 16 October 2025 6 minute read ![A hospital reception counter](https://idataraya.com/landing-v2/insights/claims-follow-up.jpg) ## Key Takeaways Providers measure claim submission and rarely measure claim closure, which is why the losses accumulate in the gap between the two. - An outright rejection is visible and gets worked. A query, a partial payment, or silence produces no alert and no owner, and those are where the money goes. - Ageing has to be counted from the last event on the claim, not from the date of service, or a claim queried twice looks younger than it is. - The number that matters is not claims submitted. It is claims submitted and not yet settled, grouped by who is currently expected to act. Most of what a provider loses to panel and insurer claims is never rejected. It is queried, short-paid, or left sitting until someone notices it during a write-off review months later. Ask a private hospital or clinic group how its claims are performing and you will usually be shown submission figures: how many went out, how quickly, how many came back rejected. Those are the measurable events, so those are the ones on the report. Then ask what proportion of claims submitted six months ago have been settled in full. That number is often not readily available, and when it is assembled, it is smaller than anyone expected. ## Rejection is the easy failure An outright rejection is a good outcome, operationally speaking. It arrives, it is unambiguous, it names a reason, and somebody is assigned to fix and resubmit it. Rejections get worked because they are visible. The losses accumulate in the states that are not rejections. A claim queried for more documentation, which sits waiting for a discharge summary nobody was asked for. A claim paid at less than the amount billed, where the shortfall is small enough that nobody queries it and consistent enough that it repeats every month. A claim acknowledged and then simply not paid, sitting in a state that generates no notification because nothing happened. None of those produce an alert. All of them produce a balance that is still technically receivable and practically ageing. ## The ageing clock is usually wrong Most receivables reports age a claim from the date of service or the date of submission. That is the wrong clock for follow-up work. What determines whether a claim needs attention today is when something last happened to it and who is currently expected to act. A claim submitted in January, queried in February, responded to in March, and queried again in April is not a four-month-old claim needing escalation. It is a two-week-old claim awaiting the insurer. A claim submitted in March with no event since is a two-month silence, and it is the one that needs a phone call. Age from the last event, split by whose turn it is, and the follow-up list reorders itself into something a person can work through. ## Short payment is a pattern, not an incident The most under-investigated category is the claim paid at less than billed. Individually each shortfall is small and arguing it costs more than it recovers. Collectively, when the same item is short-paid the same way every time, it is a pricing or coding disagreement that has never been raised with anyone who could settle it. Seeing that requires comparing billed to paid at line level and grouping the differences by item and by payer rather than by claim. Almost no provider does this, because the claim is the unit everything else is organised around, and the pattern only appears when you break the claim apart. Once it appears, it is usually a single conversation with a panel, not a recovery exercise across hundreds of claims. Share Subscribe Get new field notes when we publish them [Enter email](https://idataraya.com/contact/) ## Related content [Industry Health Care Read](https://idataraya.com/industries/health-care/) [Field note The front desk is not an integration layer Read](https://idataraya.com/insights/front-desk-integration-layer/) [Field note Semester close is a systems problem, not a finance problem Read](https://idataraya.com/insights/semester-close/) [Field note The same student, twice, and the fee nobody is chasing Read](https://idataraya.com/insights/duplicate-student-records/) [Field note Your outlets are separate businesses sharing one balance sheet Read](https://idataraya.com/insights/outlets-one-balance-sheet/) [Field note Seasonal hiring is a software requirement Read](https://idataraya.com/insights/seasonal-hiring-software/) [Field note Cash on delivery is a control problem before it is a payments problem Read](https://idataraya.com/insights/cash-on-delivery-control/) [Field note Vacant possession is where developers lose their own data Read](https://idataraya.com/insights/vacant-possession-data/) [Field note Progressive billing belongs with certification, not beside it Read](https://idataraya.com/insights/progressive-billing-certification/) --- --- title: "Semester close is a systems problem, not a finance problem | idataraya" description: "When fees, campus takings and settlement live in different places, closing the term becomes an exercise in proving that three records describe the same months. The fortnight it costs is a design decision nobody made on purpose." url: "https://idataraya.com/insights/semester-close/" --- Education # Semester close is a systems problem, not a finance problem By Halim Abdullah, Tan Yee Ling and Meera Rajendran for idataraya Field note 30 October 2025 6 minute read ![A university campus corridor](https://idataraya.com/landing-v2/insights/semester-close.jpg) ## Key Takeaways The finance office is not slow. It is reassembling one term from three systems that were never asked to agree. - Fees, campus retail, and bank settlement each hold part of the term and use different identifiers, so nothing joins without a person in the middle. - The reconciling work is concentrated at close because nothing forced the records to agree while the term was running. - Continuous matching turns a fortnight of assembly into a short list of genuine exceptions, without changing anyone's process. When fees, campus takings and settlement live in different places, closing the term becomes an exercise in proving that three records describe the same months. The fortnight it costs is a design decision nobody made on purpose. In most Malaysian colleges and universities, the fortnight after a semester ends is quietly the busiest fortnight the finance office has. Not because anything went wrong, but because everything that was never checked during the term arrives at the same time. The work has a distinctive shape. It is not accounting. It is matching: taking a fee record, a bank credit, a cafeteria takings sheet and a card settlement file, and establishing that they refer to the same fourteen weeks. ## Three records of the same term A student fee is billed in a student system, keyed by student number. It is paid into a bank account, keyed by whatever reference the payer happened to type, which is frequently a name, an old matric number, or nothing. Campus retail runs through point of sale, keyed by outlet and shift. Card and QR takings settle from an acquirer, keyed by terminal and batch. Four identifiers, none of which appear in more than one of those systems. Every join between them is therefore performed by a person, usually with a spreadsheet, usually at the end of the term. Nothing was wrong for fourteen weeks. It was simply never checked, and the checking all arrived at once. > Nothing was wrong for fourteen weeks. It was simply never checked, and the checking all arrived at once. ## Why the unmatched payment is the whole problem The single largest consumer of time at close is the payment that arrived and cannot be attributed. A parent transfers fees with the reference left blank. A sibling pays for two students in one transfer. A student pays the exact amount of an instalment three weeks late, by which point a reminder has already gone out. Each of those is a small puzzle, and each is solvable in about four minutes by someone who knows the cohort. Several hundred of them is a fortnight. The fix is not better instructions to payers, which has been tried everywhere and works partially at best. It is a payment reference the institution controls and the payer cannot get wrong, issued with the bill and carried through to the bank record. ## Campus takings are not petty The other half of close is campus retail: cafeterias, bookshops, hostels, printing, event tickets. Individually small, collectively material, and almost always reconciled last because nobody considers it the important part. It is the part with the most outlets, the most staff turnover, and the least system discipline. It also has a genuinely useful property: it settles daily through an acquirer, so it can be reconciled daily by anyone who decides to. Institutions that reconcile campus takings each morning do not have a campus takings problem at close, and they did not add headcount to achieve that. ## Move the work into the term None of this requires a single system. It requires that the records be joinable while the term is running rather than after it ends. A controlled payment reference on every bill. Bank credits matched against expected instalments automatically, with only the genuinely ambiguous ones surfaced. Acquirer settlement matched to point of sale daily rather than at term end. An exception list that is short because it is worked continuously rather than long because it is worked once. The finance office was never slow. It was doing fourteen weeks of matching in ten days because that was the first moment anything asked it to. Share Subscribe Get new field notes when we publish them [Enter email](https://idataraya.com/contact/) ## Related content [Industry Education Read](https://idataraya.com/industries/education/) [Field note The same student, twice, and the fee nobody is chasing Read](https://idataraya.com/insights/duplicate-student-records/) [Field note Your outlets are separate businesses sharing one balance sheet Read](https://idataraya.com/insights/outlets-one-balance-sheet/) [Field note Seasonal hiring is a software requirement Read](https://idataraya.com/insights/seasonal-hiring-software/) [Field note Cash on delivery is a control problem before it is a payments problem Read](https://idataraya.com/insights/cash-on-delivery-control/) [Field note Vacant possession is where developers lose their own data Read](https://idataraya.com/insights/vacant-possession-data/) [Field note Progressive billing belongs with certification, not beside it Read](https://idataraya.com/insights/progressive-billing-certification/) [Field note Billing errors do not start in billing, they start in the lease Read](https://idataraya.com/insights/billing-starts-in-the-lease/) [Field note The building outlives every system bought for it Read](https://idataraya.com/insights/building-outlives-its-systems/) --- --- title: "The same student, twice, and the fee nobody is chasing | idataraya" description: "Duplicate student records are where fee arrears quietly go to be forgotten. One record underneath admissions, billing and the bursar removes the problem rather than reporting on it." url: "https://idataraya.com/insights/duplicate-student-records/" --- Systems # The same student, twice, and the fee nobody is chasing By Syafiq Nordin, Cheong Li Wen and Anand Dorai for idataraya Field note 13 November 2025 5 minute read ![Students at a registration desk](https://idataraya.com/landing-v2/insights/duplicate-student-records.jpg) Duplicate student records are where fee arrears quietly go to be forgotten. One record underneath admissions, billing and the bursar removes the problem rather than reporting on it. A student applies in March, is offered a place, and pays a deposit. In July they defer. In January they return, and because the intake is handled by a different team using a different form, they are entered again. There are now two records for one person. One carries the deposit. The other carries the enrolment. Neither carries both, and the fee ledger sees two students who each owe part of a bill. ## Why duplicates form in the first place Duplication is rarely carelessness. It is what happens when the same person enters an institution through more than one door. A student appears at application, again at enrolment, again at hostel allocation, again in a professional programme with its own admissions process. Add a legal name spelled two ways, a passport number for an international student that changes on renewal, and an identity card number entered once with dashes and once without, and matching by name or number stops being reliable. Malaysian institutions have an additional wrinkle: many students are known day to day by a name that is a fragment of their full legal name, and which fragment gets typed depends on who is typing. > Neither record is wrong. Between them they describe one person who owes money, and neither of them shows it. ## The arrears that nobody owns The financial consequence is specific. Arrears chasing works from a list of students with outstanding balances above a threshold. A student split across two records has two balances, each below the threshold, and appears on no list. Meanwhile the deposit sits credited against a record with no enrolment, so it is not applied to the bill it was paid for. Twelve months later a reconciliation finds an unapplied credit and an unexplained arrear, and it takes someone who remembers the case to connect them. Neither record is wrong. Between them they describe one person who owes money, and neither of them shows it. ## Merging is the visible half of the fix Institutions that notice the problem usually respond with a cleanup: find the duplicates, merge them, correct the balances. That is necessary and it is not sufficient, because the doors that created them are still open and the next intake will produce more. The durable fix is that admissions, billing, hostel, and the bursar read one student record rather than each holding their own. Where a second system genuinely must exist, it references the identity rather than copying it, so a correction in one place is a correction everywhere. That also changes what a merge means. When one record is the identity and everything else points at it, merging two records is a single operation that immediately repairs the balance, the deposit, and the arrears list together, rather than three separate corrections that have to be done in the right order. Share Subscribe Get new field notes when we publish them [Enter email](https://idataraya.com/contact/) ## Related content [Industry Education Read](https://idataraya.com/industries/education/) [Field note The building outlives every system bought for it Read](https://idataraya.com/insights/building-outlives-its-systems/) [Field note Most payroll errors are entered, not calculated Read](https://idataraya.com/insights/payroll-errors-are-entered/) [Field note The workarounds are the requirements Read](https://idataraya.com/insights/workarounds-are-requirements/) [Field note The online store that sells what the counter already sold Read](https://idataraya.com/insights/online-store-oversell/) [Field note Your outlets are separate businesses sharing one balance sheet Read](https://idataraya.com/insights/outlets-one-balance-sheet/) [Field note Seasonal hiring is a software requirement Read](https://idataraya.com/insights/seasonal-hiring-software/) [Field note Cash on delivery is a control problem before it is a payments problem Read](https://idataraya.com/insights/cash-on-delivery-control/) [Field note Vacant possession is where developers lose their own data Read](https://idataraya.com/insights/vacant-possession-data/) --- --- title: "Your outlets are separate businesses sharing one balance sheet | idataraya" description: "Rooms, food and beverage, retail and tickets each behave differently and are usually measured differently too. Consolidating them after the fact is why a group learns how its month went a fortnight late." url: "https://idataraya.com/insights/outlets-one-balance-sheet/" --- Hospitality # Your outlets are separate businesses sharing one balance sheet By Mazlan Hussin, Ng Pei Shan and Kumaran Velu for idataraya Field note 27 November 2025 6 minute read ![A hotel lobby reception area](https://idataraya.com/landing-v2/insights/outlets-one-balance-sheet.jpg) ## Key Takeaways A hospitality group is not one business with several tills. It is several businesses with genuinely different economics, reported as though they were the same. - Rooms, F&B, retail, and attractions differ in how revenue is recognised, when cash arrives, and what a unit of sale even is, so a single consolidated figure hides more than it shows. - Most groups can produce a daily number per outlet and a monthly number per group, with nothing usable in between. - What management needs is not one number sooner. It is each outlet on its own terms, reconciled daily, with the group view derived rather than assembled. Rooms, food and beverage, retail and tickets each behave differently and are usually measured differently too. Consolidating them after the fact is why a group learns how its month went a fortnight late. A resort group runs rooms, three restaurants, a spa, a retail shop and a ticketed attraction. On the organisation chart it is one business. In every respect that determines how it makes money, it is five. Rooms sell inventory that expires nightly and is booked weeks ahead, often through an intermediary that pays later. Restaurants sell perishable goods against same-day cash. Retail carries stock and margin. The attraction sells a promise redeemable at a future date. The spa sells labour that cannot be stored. Those are five different economic shapes, and they resist being added together in any way that is meaningful on its own. ## The daily number and the monthly number Ask most groups what they can see and the answer is a daily takings figure per outlet, and a monthly management account for the group. Between those two there is usually nothing. The daily figure is real but shallow: it tells you what came through the till and not what it cost, what was comped, what was an advance deposit for a future stay, or what will be clawed back by an online travel agent's commission. The monthly account is complete but late, because producing it means gathering point of sale data from several systems, the property management system, the ticketing platform, acquirer settlement, and a set of spreadsheets, then arguing about the parts that do not agree. ## Where the argument always happens Three joins account for most of the delay at close in a multi outlet group. The first is the room charge posted to a folio: a guest signs for dinner, the restaurant records a sale, the room bills it later, and until the folio settles those are two records of one transaction. Counting both inflates revenue, counting neither loses it, and deciding which is which is manual in most groups. The second is the intermediary booking, where the guest pays a platform and the property receives a net amount at an unrelated time. The gross, the commission, and the receipt each belong to a different day. The third is the deposit for a future stay or event, which is cash today and revenue later, and which is routinely reported as either both or neither. ## Consolidate from a shared spine, not from reports Groups usually attack this by standardising the report. Everybody submits the same template, so the arithmetic at the top is at least consistent. That improves the presentation and changes nothing about the delay, because the work was never the arithmetic. It was establishing what the underlying records meant. The alternative is to fix the joins rather than the summary. One product and outlet structure across every till so a sale means the same thing everywhere. Folio postings recognised as transfers rather than sales at the point they are created. Intermediary bookings modelled with gross, commission, and settlement as three linked facts rather than one net figure. Deposits held as liabilities that convert on a date. Do that and the group view is derived from the outlets continuously rather than assembled from them monthly. The outlets keep their own economics, which they should, and the consolidation stops being an event. Share Subscribe Get new field notes when we publish them [Enter email](https://idataraya.com/contact/) ## Related content [Industry Travel and Tourism Read](https://idataraya.com/industries/travel-tourism/) [Field note Seasonal hiring is a software requirement Read](https://idataraya.com/insights/seasonal-hiring-software/) [Field note Cash on delivery is a control problem before it is a payments problem Read](https://idataraya.com/insights/cash-on-delivery-control/) [Field note Vacant possession is where developers lose their own data Read](https://idataraya.com/insights/vacant-possession-data/) [Field note Progressive billing belongs with certification, not beside it Read](https://idataraya.com/insights/progressive-billing-certification/) [Field note Billing errors do not start in billing, they start in the lease Read](https://idataraya.com/insights/billing-starts-in-the-lease/) [Field note The building outlives every system bought for it Read](https://idataraya.com/insights/building-outlives-its-systems/) [Field note Whose records are they when the managing agent changes Read](https://idataraya.com/insights/whose-records-managing-agent/) [Field note Arrears are a process, and the process needs a trail Read](https://idataraya.com/insights/arrears-need-a-trail/) --- --- title: "Seasonal hiring is a software requirement | idataraya" description: "If counter software takes a week to learn, it will be half-learned by the second intake. The complexity belongs in the system, not in the training deck." url: "https://idataraya.com/insights/seasonal-hiring-software/" --- Operations # Seasonal hiring is a software requirement By Aishah Roslan, Foo Chee Keong and Divya Sathish for idataraya Field note 11 December 2025 5 minute read ![Staff working behind a cafe counter](https://idataraya.com/landing-v2/insights/seasonal-hiring-software.jpg) If counter software takes a week to learn, it will be half-learned by the second intake. The complexity belongs in the system, not in the training deck. Retail, food service and tourism operators in Malaysia run on intakes. School holidays, Ramadan and Raya, year end, a festival weekend, a new outlet opening. Each intake brings people who will be on the counter within days and gone within months, and who will be replaced by another set who have never seen the system either. Software specified without that in mind gets specified for the person who has used it for two years. That person is a minority of the people who will actually touch it. ## The training deck is a symptom When counter software is hard, the response is almost always training: a deck, a half day session, a laminated card by the till. It works, in the sense that people can complete the tasks afterwards, and it fails in the sense that the requirement recurs every intake forever. Training is not a fix for a confusing system. It is a recurring payment on one, and unlike a licence fee, nobody puts it in the business case. The test is simple and rarely applied: can a new hire complete the ten most common tasks correctly, without help, on their first shift. Not eventually. On the first shift, with a queue. > Training is not a fix for a confusing system. It is a recurring payment on one. ## What actually causes errors at a counter The mistakes new staff make are consistent and they are mostly not about the transaction itself. Selecting the wrong item from a list of similar names. Applying a discount that should have needed approval. Taking a payment method the outlet does not settle. Voiding rather than refunding, or the reverse. Starting a new sale before the previous one was closed. Each of those is a design decision presented as a training gap. A list ordered by frequency rather than alphabetically removes the first. A rule that requires approval, rather than a policy that asks for it, removes the second. Configuring only the payment methods the outlet actually accepts removes the third. The pattern is the same each time: move the correctness from the person to the system, and the intake stops mattering. ## Design for the worst shift, not the best The conditions that matter are not the demonstration conditions. They are the third hour of a public holiday queue, on the busiest till, operated by someone in their second week, with a supervisor helping elsewhere. Software that works then has particular properties. Few decisions per sale. Destructive actions that are hard to reach and easy to reverse. Errors that say what to do rather than what went wrong. A screen that does not change shape depending on the path taken to reach it. Nothing that requires remembering a code. None of that is sophisticated. It is simply what happens when the specification is written for the staff an operator will actually have, rather than the staff it has today. Share Subscribe Get new field notes when we publish them [Enter email](https://idataraya.com/contact/) ## Related content [Industry Travel and Tourism Read](https://idataraya.com/industries/travel-tourism/) [Field note Arrears are a process, and the process needs a trail Read](https://idataraya.com/insights/arrears-need-a-trail/) [Field note The third-year cloud bill Read](https://idataraya.com/insights/third-year-cloud-bill/) [Field note Taking over a system you did not build: the first ninety days Read](https://idataraya.com/insights/inheriting-a-system/) [Field note An untested restore is a belief, not a backup Read](https://idataraya.com/insights/untested-restore/) [Field note One catalogue, or the argument you have every month Read](https://idataraya.com/insights/one-catalogue/) [Field note Your terminal estate is a logistics business. Run it like one. Read](https://idataraya.com/insights/provisioning-a-terminal-fleet/) [Field note Cash on delivery is a control problem before it is a payments problem Read](https://idataraya.com/insights/cash-on-delivery-control/) [Field note Vacant possession is where developers lose their own data Read](https://idataraya.com/insights/vacant-possession-data/) --- --- title: "Cash on delivery is a control problem before it is a payments problem | idataraya" description: "The exposure is not in accepting the money. It is in knowing which run it belonged to. Recording collection at the door is what turns a monthly shortfall into a same-day question." url: "https://idataraya.com/insights/cash-on-delivery-control/" --- Logistics # Cash on delivery is a control problem before it is a payments problem By Zainal Arifin, Loke Han Wei, Sivakumar Raju and Nadia Kamil for idataraya Field note 8 January 2026 7 minute read ![A courier on a motorcycle making a delivery](https://idataraya.com/landing-v2/insights/cash-on-delivery-control.jpg) ## Key Takeaways Cash on delivery fails quietly, and it fails at the point where custody changes without a record, not at the point where cash is counted. - Every handover of cash without a record at the moment it happens creates a window in which a shortfall cannot be attributed to a run, a driver, or a stop. - Reconciling at the depot at the end of a day means the earliest possible detection is hours after the earliest possible cause. - Recording collection at the door, offline if necessary, converts a monthly investigation into a question asked the same afternoon. The exposure is not in accepting the money. It is in knowing which run it belonged to. Recording collection at the door is what turns a monthly shortfall into a same-day question. Cash on delivery remains a large share of Malaysian e-commerce and a larger share outside the Klang Valley. Sellers accept it because refusing it costs orders. Logistics operators accept it because sellers ask for it. Almost nobody designs for it, because on paper it is simple: the driver collects the money and hands it in. The difficulty is not in either of those actions. It is in everything that is not recorded between them. ## Custody changes more often than anyone counts Trace a hundred ringgit through a typical run. The customer hands it to the driver at the door. The driver holds it alongside collections from other stops. At the end of the shift, the driver hands the total to a depot supervisor. The supervisor holds it with other drivers' totals. It is banked the next morning, and appears in the seller's remittance days later. That is at least four changes of custody, and in most operations exactly one of them, the banking, produces a record at the moment it occurs. The other three are reconstructed later from a manifest, a memory, and a count. Anywhere custody changes without a record is a place where a difference can arise and cannot afterwards be attributed. > A shortfall that surfaces at month end is not a bigger version of a shortfall that surfaces at four o'clock. It is a different problem, because by then nobody can say which stop it came from. ## Why end-of-day reconciliation is too late Most operators reconcile at the depot: the driver's cash is counted against the stops marked delivered. If it balances, the run closes. If it does not, an investigation starts. The investigation is hard for a structural reason. By the time counting happens, the driver has completed twenty or thirty stops over eight hours, and there is no per stop record to compare against. The available evidence is a total that is short and a list of addresses. Establishing where the difference arose means calling customers, which nobody wants to do, or writing it off, which is what usually happens. A shortfall that surfaces at month end is not a bigger version of a shortfall that surfaces at four o'clock. It is a different problem, because by then nobody can say which stop it came from. ## The failures that are not theft It is worth being precise about what goes wrong, because assuming dishonesty produces controls that punish the wrong thing. A customer pays part of the amount and promises the rest, and the driver accepts it rather than take the parcel back. A parcel is left with a neighbour or a guard house and the cash is collected later, or never. A return is handed back at the door and the collection is reversed informally. Two parcels for one address are consolidated by the customer into one payment and split incorrectly. A driver covers a shortfall from their own pocket to close the run, which hides a real problem permanently. Every one of those is a legitimate operational event that the system had no way to record, so it was resolved by a person and became invisible. ## Record at the door or do not record at all The single change that matters is capturing the collection where it happens: the stop, the amount actually received, the condition of the delivery, and the time, entered by the driver at the door. This is where most attempts fail, because the door is exactly where connectivity is worst: a basement car park, a rural stretch, a lift lobby, a guarded compound. An application that requires a live connection to record a collection will simply not be used at the stops that matter most, and the run reverts to paper. So the requirement is not a mobile application. It is a mobile application that records the collection locally, works with the network entirely absent, and reconciles when it next has coverage. The record is created at the door regardless. ## What changes when the record exists With a per stop collection record, the depot count stops being an investigation and becomes an assertion: this driver collected these amounts at these stops, totalling this figure, and here is what was handed in. A difference now has a location. It is one stop, or two, and the question is specific enough to answer the same afternoon while the driver still remembers the address. Partial payments become a recorded state rather than an informal arrangement. Consolidated payments are split at the point of collection rather than reconstructed later. The cash has not moved any differently. The difference is that every change of custody now leaves a trace, and a shortfall has somewhere to be found. Share Subscribe Get new field notes when we publish them [Enter email](https://idataraya.com/contact/) ## Related content [Industry Transportation and Logistics Read](https://idataraya.com/industries/transportation-logistics/) [Field note Vacant possession is where developers lose their own data Read](https://idataraya.com/insights/vacant-possession-data/) [Field note Progressive billing belongs with certification, not beside it Read](https://idataraya.com/insights/progressive-billing-certification/) [Field note Billing errors do not start in billing, they start in the lease Read](https://idataraya.com/insights/billing-starts-in-the-lease/) [Field note The building outlives every system bought for it Read](https://idataraya.com/insights/building-outlives-its-systems/) [Field note Whose records are they when the managing agent changes Read](https://idataraya.com/insights/whose-records-managing-agent/) [Field note Arrears are a process, and the process needs a trail Read](https://idataraya.com/insights/arrears-need-a-trail/) [Field note Parallel running is not caution, it is the test Read](https://idataraya.com/insights/parallel-running-is-the-test/) [Field note Most payroll errors are entered, not calculated Read](https://idataraya.com/insights/payroll-errors-are-entered/) --- --- title: "Vacant possession is where developers lose their own data | idataraya" description: "The management office almost always starts from an empty system, re-entering purchasers, warranties and defects the developer already held. That handover is a design decision, and it is usually made by not making it." url: "https://idataraya.com/insights/vacant-possession-data/" --- Property # Vacant possession is where developers lose their own data By Rahmat Selamat, Chua Ming Hui and Lakshmi Naidu for idataraya Field note 22 January 2026 6 minute read ![Keys being handed over for a new home](https://idataraya.com/landing-v2/insights/vacant-possession-data.jpg) ## Key Takeaways Everything the management office spends its first year rebuilding already existed inside the developer's systems on the day of handover. - Purchaser details, unit specifications, warranty terms and the defect history are all held by the developer and almost never transferred in usable form. - The defect liability period runs from vacant possession, so the management office inherits an obligation without inheriting the record it depends on. - Handover is treated as a legal event and not as a data event, which is why the second one is discovered rather than planned. The management office almost always starts from an empty system, re-entering purchasers, warranties and defects the developer already held. That handover is a design decision, and it is usually made by not making it. A development completes. Certificates are issued, vacant possession notices go out, purchasers collect keys, and a management office opens on site. Within a fortnight that office is doing something odd: telephoning purchasers to ask for details the developer already has. Names, contact numbers, unit numbers, car park bays, handover dates, whether a defect was raised before collection, what was fitted in the unit and by whom. All of it existed. None of it arrived. ## Two organisations, one building, no shared record The developer's systems are built for selling: a sales and purchase pipeline, progress billing, loan documentation, purchaser correspondence. The management office's systems are built for operating: service charges, sinking fund, access control, work orders, defect tracking. Those are genuinely different concerns and it is reasonable that they are different systems. What is not reasonable is that the transition between them is usually a set of PDFs and a spreadsheet of names, produced by whoever is available in the week of handover. The developer did not lose the data. It kept it, in a system the management office has no access to, in a shape nobody asked it to produce. > The developer did not lose the data. It kept it, in a system the management office has no access to, in a shape nobody asked it to produce. ## The defect liability period is the sharpest case Under the standard statutory sale agreements, the defect liability period runs from the date of vacant possession, and purchasers raise defects through that window to the developer. In practice, most purchasers raise them to the management office, because that is the office in the building. The management office then forwards them, tracks them in its own system, chases the contractor, and inspects the rectification. So the party doing the operational work has no access to the defect list compiled at handover inspection, no view of what the developer already accepted or rejected, and no copy of the warranty terms for the equipment involved. It rebuilds all three from purchaser complaints, one at a time, over the first year. ## What a real handover contains The useful version of this is not complicated, it is simply specified in advance rather than assembled at the end. A purchaser register with unit, contact, and handover date, in a form that loads rather than a form that prints. The unit schedule with share units, parking allocation, and any variation from standard specification. Asset and warranty records for plant and equipment, with supplier, commissioning date, and warranty expiry. The defect list as it stood at handover, with status. Meter numbers and opening readings. Approved drawings and the certificates for the building's systems. Each of those exists somewhere in the developer's organisation on handover day. The difference between a good handover and a poor one is whether anyone was made responsible for producing them in a usable shape before the office opened. ## Make it a deliverable, not a courtesy Developers with several projects running eventually work this out, usually after the second or third management office spends a year rebuilding records. The ones who solve it treat the handover data set as a project deliverable with an owner, a format, and a date, the same as the certificates. Where the developer also holds the management contract for the first period, the case is even stronger, because the cost of the rebuild lands on the developer's own team. The building will outlive the developer's involvement in it by decades. What it is handed on day one determines how much of its own history it has for the rest of that time. Share Subscribe Get new field notes when we publish them [Enter email](https://idataraya.com/contact/) ## Related content [Industry Property Developers Read](https://idataraya.com/industries/property-developers/) [Field note Progressive billing belongs with certification, not beside it Read](https://idataraya.com/insights/progressive-billing-certification/) [Field note Billing errors do not start in billing, they start in the lease Read](https://idataraya.com/insights/billing-starts-in-the-lease/) [Field note The building outlives every system bought for it Read](https://idataraya.com/insights/building-outlives-its-systems/) [Field note Whose records are they when the managing agent changes Read](https://idataraya.com/insights/whose-records-managing-agent/) [Field note Arrears are a process, and the process needs a trail Read](https://idataraya.com/insights/arrears-need-a-trail/) [Field note Parallel running is not caution, it is the test Read](https://idataraya.com/insights/parallel-running-is-the-test/) [Field note Most payroll errors are entered, not calculated Read](https://idataraya.com/insights/payroll-errors-are-entered/) [Field note Automating a step nobody was waiting on Read](https://idataraya.com/insights/automating-the-wrong-step/) --- --- title: "Progressive billing belongs with certification, not beside it | idataraya" description: "When claims are raised from one record and certified in another, every cycle produces a reconciliation and some of them produce a dispute. Holding both together removes the work rather than speeding it up." url: "https://idataraya.com/insights/progressive-billing-certification/" --- Property # Progressive billing belongs with certification, not beside it By Iskandar Yusri, Wong Kah Yan and Suresh Nadarajah for idataraya Field note 5 February 2026 6 minute read ![An engineer inspecting work on a construction site](https://idataraya.com/landing-v2/insights/progressive-billing-certification.jpg) When claims are raised from one record and certified in another, every cycle produces a reconciliation and some of them produce a dispute. Holding both together removes the work rather than speeding it up. Progress billing in Malaysian residential development follows a defined path. A stage of work completes, the architect certifies it, and on the strength of that certificate the developer bills purchasers and purchasers' financiers release the corresponding portion. The path is clear. What is usually unclear is which system holds the truth at each step, because the certificate lives with the project team and the billing lives with finance, and the two are joined by a person sending a document. ## The transcription in the middle In most developers the sequence is: the architect issues a certificate for a stage, the project team circulates it, finance reads it, finance raises billings against the units affected, and those billings go to purchasers and to end financiers. Every one of those steps is reasonable, and the join between certification and billing is a human reading one document and typing into another. That is where the errors live: a stage certified for one block billed against two, a unit that was sold after the previous cycle and missed in this one, a purchaser whose financier requires the certificate attached and did not receive it, a rebilling after a certificate was amended. A billing system that cannot see the certificate is not billing. It is transcribing, and transcription is where the disputes come from. > A billing system that cannot see the certificate is not billing. It is transcribing, and transcription is where the disputes come from. ## Why the errors are expensive out of proportion A wrong billing in progressive development is not a wrong invoice. It sits in the middle of a financing chain. The purchaser receives a demand. Their financier receives the same demand with the supporting certificate and releases against it. If the amount, the stage, or the unit is wrong, the release is delayed while it is queried, the developer's cash flow moves, and the purchaser receives a reminder for something they did not owe. Correcting it is not a credit note. It is a credit note, a reissued demand, a re-submission to the financier, and an explanation to a purchaser who is now paying attention to everything else you send them. ## Hold the certificate as the billing event The structural fix is to make the certificate the thing that triggers billing rather than the thing that authorises someone to bill. In practice that means the certificate is recorded once, against a stage and a defined scope of units, and the billing run is generated from it. Which units are billed is derived from the sales register at that moment, so a unit sold last week is included without anyone remembering. The certificate reference and document travel with the demand automatically, so the financier's requirement is satisfied by construction rather than by attachment. An amended certificate then has an obvious behaviour: it supersedes, and what was billed from the previous version is identifiable in one query rather than reconstructed from correspondence. ## What this changes at cycle close The visible benefit is that a billing cycle stops requiring a reconciliation. The claims raised match the stages certified because they were produced from them, and the exceptions are genuine exceptions rather than transcription differences. The less visible benefit matters more over a long project. Every billing carries the certificate that justified it, permanently. When a purchaser queries a demand from two years ago, or a financier audits a release, or a dispute reaches a point where the sequence matters, the answer is a record rather than an exercise. The work was never in raising the claims. It was in proving afterwards that they were right. Share Subscribe Get new field notes when we publish them [Enter email](https://idataraya.com/contact/) ## Related content [Industry Property Developers Read](https://idataraya.com/industries/property-developers/) [Field note Vacant possession is where developers lose their own data Read](https://idataraya.com/insights/vacant-possession-data/) [Field note Billing errors do not start in billing, they start in the lease Read](https://idataraya.com/insights/billing-starts-in-the-lease/) [Field note The building outlives every system bought for it Read](https://idataraya.com/insights/building-outlives-its-systems/) [Field note Whose records are they when the managing agent changes Read](https://idataraya.com/insights/whose-records-managing-agent/) [Field note Arrears are a process, and the process needs a trail Read](https://idataraya.com/insights/arrears-need-a-trail/) [Field note Parallel running is not caution, it is the test Read](https://idataraya.com/insights/parallel-running-is-the-test/) [Field note Most payroll errors are entered, not calculated Read](https://idataraya.com/insights/payroll-errors-are-entered/) [Field note Automating a step nobody was waiting on Read](https://idataraya.com/insights/automating-the-wrong-step/) --- --- title: "Billing errors do not start in billing, they start in the lease | idataraya" description: "When rent reviews and variations are recorded in one place and billed from another, the two drift apart quietly and are reconciled by credit note. Producing the bill from the lease removes the gap rather than auditing it." url: "https://idataraya.com/insights/billing-starts-in-the-lease/" --- Commercial property # Billing errors do not start in billing, they start in the lease By Noraini Zakaria, Gan Teck Soon and Arjun Balakrishnan for idataraya Field note 19 February 2026 6 minute read ![Contract documents being signed at a desk](https://idataraya.com/landing-v2/insights/billing-starts-in-the-lease.jpg) ## Key Takeaways A commercial billing run is only as accurate as the last time somebody remembered to tell the billing system what the lease now says. - Rent reviews, rent free periods, staged increases and area variations are agreed in documents and applied in a billing table, and nothing enforces that the two agree. - Credit notes are the usual repair, which fixes the amount and leaves the underlying record still wrong for next month. - When the lease terms are the billing terms, a variation is recorded once and every future bill follows from it. When rent reviews and variations are recorded in one place and billed from another, the two drift apart quietly and are reconciled by credit note. Producing the bill from the lease removes the gap rather than auditing it. A tenant queries their invoice. The property manager checks, agrees, and raises a credit note. Next month the same invoice arrives with the same error, because the credit note corrected the bill and not the reason for it. This is the most ordinary failure in commercial property billing, and it is almost never a billing system defect. It is a gap between where terms are agreed and where they are applied. ## What a lease actually says A commercial lease is not a rent figure. It is a schedule of obligations over time: a base rent, a review at a stated date on a stated basis, a rent free or half rent period at the start, a service charge on a proportion that may be defined by lettable area or by a fixed share, a car park allocation with its own rate, utilities either metered or apportioned, and an escalation that may apply to some of those and not others. Then it changes. Space is added or given back. A review is agreed at a figure different from the formula. A fit out period is extended. An assignment moves the covenant to a new entity. A side letter grants a temporary abatement. Each of those is agreed properly, documented properly, and filed properly. Whether it reaches the billing table depends on somebody doing a second, separate act of data entry. ## Drift is quiet and cumulative The failure mode is not a dramatic error. It is a small, persistent divergence that nobody notices because each month looks like the previous month. A review date passes and the increase is not applied, so the tenant underpays for eight months and is then asked for a large arrear they did not budget for. A rent free period ends and billing does not start, or starts a month early. An area variation is reflected in rent but not in the service charge apportionment, so every other tenant in the building is now carrying a fraction of it. That last one is the reason this matters beyond the individual tenant. Service charge apportionment is a zero sum arrangement across a building. An error in one lease is a small overcharge to everyone else, and it is discovered at the annual reconciliation if it is discovered at all. ## Bill from the terms, not from a copy of them The alternative is that the lease record is the billing basis: the charge lines, their bases, their review dates, and their escalation rules held once, with the billing run derived from them on the day it runs. A variation is then recorded against the lease and the billing follows automatically, including the parts a person would have forgotten, such as the apportionment consequences for the rest of the building. A review that has not been settled shows as a review that has not been settled, rather than as a rent that quietly stayed the same. This is also what makes the annual service charge reconciliation tractable, because the apportionments used through the year came from the same record as the areas, rather than from a table maintained beside it. ## The credit note is the diagnostic A useful measure for any commercial portfolio is the proportion of billings that are subsequently adjusted, and the reason for each. Adjustments caused by genuine events, an early surrender, a negotiated abatement, are unavoidable and should be there. Adjustments caused by a term that was agreed and not applied are a measurement of the gap between two systems, and they are the ones worth counting. Portfolios that count them are usually surprised, and they usually stop needing to count them within a year of closing the gap. Share Subscribe Get new field notes when we publish them [Enter email](https://idataraya.com/contact/) ## Related content [Industry Malls and Commercial Property Read](https://idataraya.com/industries/commercial-property/) [Field note The building outlives every system bought for it Read](https://idataraya.com/insights/building-outlives-its-systems/) [Field note Whose records are they when the managing agent changes Read](https://idataraya.com/insights/whose-records-managing-agent/) [Field note Arrears are a process, and the process needs a trail Read](https://idataraya.com/insights/arrears-need-a-trail/) [Field note Parallel running is not caution, it is the test Read](https://idataraya.com/insights/parallel-running-is-the-test/) [Field note Most payroll errors are entered, not calculated Read](https://idataraya.com/insights/payroll-errors-are-entered/) [Field note Automating a step nobody was waiting on Read](https://idataraya.com/insights/automating-the-wrong-step/) [Field note If nobody can check the answer, it cannot go into production Read](https://idataraya.com/insights/checkable-answers/) [Field note Test on the phones your staff actually carry Read](https://idataraya.com/insights/test-on-real-phones/) --- --- title: "The building outlives every system bought for it | idataraya" description: "Leasing, car park and maintenance are usually bought a decade apart from three vendors, and the management office becomes the integration between them. That cost never appears in any of the three business cases." url: "https://idataraya.com/insights/building-outlives-its-systems/" --- Systems # The building outlives every system bought for it By Shahrul Nizam, Khoo Ai Lin, Rajesh Muniandy and Fatimah Daud for idataraya Field note 5 March 2026 7 minute read ![The facade of a modern office tower](https://idataraya.com/landing-v2/insights/building-outlives-its-systems.jpg) Leasing, car park and maintenance are usually bought a decade apart from three vendors, and the management office becomes the integration between them. That cost never appears in any of the three business cases. A commercial building opened in 2005 has probably had four generations of tenant, three of management, and somewhere between five and ten systems bought to run parts of it. Almost none of those systems were chosen with the others in mind, because when each was bought the others either did not exist yet or were not up for replacement. The building is the constant. Everything bought to operate it is temporary, and it is bought one piece at a time. ## Three purchases, three decades, three vendors The pattern is consistent enough to be predictable. Leasing and billing come with the asset manager, chosen for a portfolio rather than for a building. Car park is chosen when the barriers are replaced, on a hardware cycle, by a vendor whose primary product is equipment. Maintenance and work orders arrive when the facilities contract changes, often as part of the contractor's own toolkit. Access control, energy monitoring, and visitor management each arrive on their own occasions, for their own reasons, from their own suppliers. Every one of those decisions was defensible in isolation. Collectively they produce a building whose operating data is distributed across six vendors, none of whom has a commercial reason to make their part legible to the others. > Nobody decided that a building manager should spend a morning a week copying figures between three screens. It is simply what was left over after three separate purchases. ## The management office becomes the integration What fills the gaps is people. A building manager who knows that the tenant list in the leasing system is authoritative but the one in access control is more current. An accounts assistant who keys car park revenue into the finance system every Monday from a report. A supervisor who raises a work order in one system because a tenant complained in another. None of that is written down and all of it is load bearing. It also does not survive staff turnover, which in building management is not rare. Nobody decided that a building manager should spend a morning a week copying figures between three screens. It is simply what was left over after three separate purchases. ## What the fragmentation actually costs The obvious cost is the clerical time, and it is the smallest of them. The larger cost is that questions spanning two systems cannot be answered. Which tenants generate the most maintenance calls relative to their rent. Whether the car park is being used by tenants under their allocation or by visitors paying casual rates. What a floor actually costs to operate, including its share of energy and reactive maintenance, against what it yields. Each of those is answerable in principle and unanswerable in practice, so it is not asked. Decisions get made on the parts that are visible, which is usually rent. The third cost is at handover. When a managing agent changes, whatever lived in people transfers badly or not at all, and the new team rebuilds it over six months. ## Design for replacement, not for integration The instinct is to buy one system that does everything, and for a single building under one management that can work. Across a portfolio with different ages, different contracts, and different equipment, it usually does not, because the replacement cycles are genuinely independent. Car park barriers wear out on their own schedule regardless of the leasing contract. The more durable posture is to accept that components will be replaced at different times, and to decide which records belong to the building rather than to a vendor. The tenant and lease register, the unit and area schedule, the asset register, and the financial history are the building's. They should live somewhere that survives a vendor change, and every operational system should read them rather than hold its own copy. A car park system should know which tenants exist because it was told, not because someone maintains a second list in it. That single discipline changes what a replacement means. It becomes swapping a component, rather than migrating a decade of records out of a product that is being switched off. Share Subscribe Get new field notes when we publish them [Enter email](https://idataraya.com/contact/) ## Related content [Industry Malls and Commercial Property Read](https://idataraya.com/industries/commercial-property/) [Field note Most payroll errors are entered, not calculated Read](https://idataraya.com/insights/payroll-errors-are-entered/) [Field note The workarounds are the requirements Read](https://idataraya.com/insights/workarounds-are-requirements/) [Field note The online store that sells what the counter already sold Read](https://idataraya.com/insights/online-store-oversell/) [Field note The same student, twice, and the fee nobody is chasing Read](https://idataraya.com/insights/duplicate-student-records/) [Field note Whose records are they when the managing agent changes Read](https://idataraya.com/insights/whose-records-managing-agent/) [Field note Arrears are a process, and the process needs a trail Read](https://idataraya.com/insights/arrears-need-a-trail/) [Field note Parallel running is not caution, it is the test Read](https://idataraya.com/insights/parallel-running-is-the-test/) [Field note Automating a step nobody was waiting on Read](https://idataraya.com/insights/automating-the-wrong-step/) --- --- title: "Whose records are they when the managing agent changes | idataraya" description: "If the billing history and the register live inside an agent's tooling, a change of agent is a data loss event. The community owns the obligation, so it should own the records." url: "https://idataraya.com/insights/whose-records-managing-agent/" --- Governance # Whose records are they when the managing agent changes By Hamzah Idris, Sim Chee Hong and Puvanes Sundram for idataraya Field note 19 March 2026 5 minute read ![Rows of archive filing cabinets](https://idataraya.com/landing-v2/insights/whose-records-managing-agent.jpg) ## Key Takeaways A management corporation carries statutory obligations that outlast every agent it appoints, and it is usually the only party in the arrangement without a copy of its own records. - The register of parcel owners, the charge history and the arrears trail belong to the community, not to whoever is administering them this year. - Handover between agents is contractual and is rarely specified in terms of data, so what transfers is a set of reports rather than a working record. - The test is simple: if the agent left next month, could the committee answer a purchaser's arrears query without asking them. If the billing history and the register live inside an agent's tooling, a change of agent is a data loss event. The community owns the obligation, so it should own the records. A management corporation changes its managing agent. The contract ends properly, the handover meeting happens, files are transferred. Three months later the new agent cannot answer a straightforward question: what was agreed with the owner of a particular parcel about a payment arrangement in the previous year. The agreement existed. It was recorded in the previous agent's system, which is not part of what transferred, because what transferred was a set of reports. ## The obligation and the record sit in different places Under Malaysian strata law the management corporation, or the joint management body before it, holds the duties: maintain the common property, levy and collect charges, keep the register of parcel owners, account for the maintenance account and the sinking fund, and answer to the Commissioner of Buildings and ultimately to the owners. The managing agent is engaged to perform that work. The obligation does not transfer with the engagement, and neither does liability for the records. Yet in most arrangements the records physically live in the agent's chosen system, under the agent's licence, accessible on the agent's terms. The party with the statutory duty is the party without the data. ## What is actually lost at handover Financial statements transfer. Balances transfer. What tends not to transfer is everything with a history rather than a total. The arrears trail for each parcel: what was demanded, when, what response came back, what arrangement was agreed and whether it was kept. Correspondence with individual owners. The maintenance history against each asset. Records of who was granted access and to what. Meter readings before the last quarter. The new agent therefore begins by treating every account as though it started at handover, which is precisely the wrong footing for the accounts that are in arrears, because those are the ones where the history is the case. ## The question that settles it Committees can test their position with one question: if the agent gave notice next month, could the committee answer a purchaser's solicitor asking about outstanding charges on a parcel, without asking the outgoing agent. If the answer is no, the community does not hold its own records, whatever the contract says about ownership. Contractual ownership of data that only exists inside somebody else's product is a claim, not a position. The practical remedy is not to run the systems in house, which few committees can. It is to hold the register, the charge history, and the arrears trail in a system engaged by the community, into which the agent works. The agent changes and the records stay, which is the correct way round for an obligation that belongs to the building. Share Subscribe Get new field notes when we publish them [Enter email](https://idataraya.com/contact/) ## Related content [Industry Strata and Condominium Read](https://idataraya.com/industries/strata-management/) [Field note If nobody can check the answer, it cannot go into production Read](https://idataraya.com/insights/checkable-answers/) [Field note Audit evidence is a feature, not a report you run later Read](https://idataraya.com/insights/audit-evidence/) [Field note Arrears are a process, and the process needs a trail Read](https://idataraya.com/insights/arrears-need-a-trail/) [Field note Parallel running is not caution, it is the test Read](https://idataraya.com/insights/parallel-running-is-the-test/) [Field note Most payroll errors are entered, not calculated Read](https://idataraya.com/insights/payroll-errors-are-entered/) [Field note Automating a step nobody was waiting on Read](https://idataraya.com/insights/automating-the-wrong-step/) [Field note Test on the phones your staff actually carry Read](https://idataraya.com/insights/test-on-real-phones/) [Field note The warehouse is rarely the problem: where reporting actually breaks Read](https://idataraya.com/insights/where-reporting-breaks/) --- --- title: "Arrears are a process, and the process needs a trail | idataraya" description: "A total tells a committee how much is owed. What it needs before deciding anything is what has already been sent, agreed and escalated on each account, with dates." url: "https://idataraya.com/insights/arrears-need-a-trail/" --- Operations # Arrears are a process, and the process needs a trail By Latifah Ahmad, Teoh Boon Siew and Naveen Chandra for idataraya Field note 2 April 2026 5 minute read ![A residential condominium building](https://idataraya.com/landing-v2/insights/arrears-need-a-trail.jpg) A total tells a committee how much is owed. What it needs before deciding anything is what has already been sent, agreed and escalated on each account, with dates. Every strata committee meeting includes an arrears figure. It is usually a single number, sometimes split into ageing buckets, and it is almost always the least useful item on the agenda, because nobody can act on it. The committee's real decisions are per account. Whether to send a final demand on this parcel. Whether an arrangement offered by that owner is reasonable given what they agreed and did not keep last year. Whether to escalate to the Tribunal. None of those can be made from a total. ## What the trail has to contain A workable arrears record for a parcel is a sequence of events with dates: charges raised, payments received, reminders issued and by what method, demands served and how service was effected, arrangements proposed, agreed, and either kept or broken, and any escalation with its outcome. That sequence is what turns an amount into a case. An owner three months in arrears who has never been contacted is a different situation from an owner three months in arrears who agreed a schedule and has kept every instalment, and both are different from one who has broken two arrangements. In a system that stores only balances, all three appear identically. > The committee is not asked to approve an amount. It is asked to approve an escalation, and that is a decision about history rather than about a figure. ## Service and evidence Recovery under the Act depends on things having been done in a particular order and being demonstrable afterwards. A demand has to have been issued and served, and if a matter reaches the Commissioner of Buildings or the Tribunal, the question is not whether the charge was owed but whether the process was followed. That makes the record of what was sent, when, to which address, by which method, and what came back the operative evidence. Reconstructing it later from a file of letters and somebody's recollection is possible and it is not comfortable, and it tends to be needed exactly on the accounts where relations have already broken down. Recording service at the time it happens costs nothing. Reconstructing it costs a hearing. ## Consistency is the other reason Committees are volunteers, they rotate, and they live in the building. Arrears decisions are made about neighbours, which makes consistency both harder and more important. A defined sequence, applied to every account, with the trail showing that it was, is the strongest protection a committee has when it is accused of being harsh on one owner and lenient with another. It also removes the most awkward part of the job, which is deciding case by case what to do next. The committee is not asked to approve an amount. It is asked to approve an escalation, and that is a decision about history rather than about a figure. Share Subscribe Get new field notes when we publish them [Enter email](https://idataraya.com/contact/) ## Related content [Industry Strata and Condominium Read](https://idataraya.com/industries/strata-management/) [Field note The third-year cloud bill Read](https://idataraya.com/insights/third-year-cloud-bill/) [Field note Taking over a system you did not build: the first ninety days Read](https://idataraya.com/insights/inheriting-a-system/) [Field note An untested restore is a belief, not a backup Read](https://idataraya.com/insights/untested-restore/) [Field note One catalogue, or the argument you have every month Read](https://idataraya.com/insights/one-catalogue/) [Field note Your terminal estate is a logistics business. Run it like one. Read](https://idataraya.com/insights/provisioning-a-terminal-fleet/) [Field note Seasonal hiring is a software requirement Read](https://idataraya.com/insights/seasonal-hiring-software/) [Field note Parallel running is not caution, it is the test Read](https://idataraya.com/insights/parallel-running-is-the-test/) [Field note Most payroll errors are entered, not calculated Read](https://idataraya.com/insights/payroll-errors-are-entered/) --- --- title: "Parallel running is not caution, it is the test | idataraya" description: "A payroll migration is the one case where matching the old system exactly is the goal. Every unexplained difference in a parallel run is a defect you would otherwise find on payday." url: "https://idataraya.com/insights/parallel-running-is-the-test/" --- Payroll # Parallel running is not caution, it is the test By Roslan Majid, Yap Hui Ying and Shanti Mohan for idataraya Field note 16 April 2026 6 minute read ![A calculator and payroll paperwork on a desk](https://idataraya.com/landing-v2/insights/parallel-running-is-the-test.jpg) ## Key Takeaways Parallel running is often cut for time because it looks like a precaution. It is the only test that exercises the whole system against a known correct answer. - Payroll is the rare system where the expected output already exists, so a difference is either a defect in the new system or an error in the old one, and both are worth knowing. - One clean cycle proves nothing. The cases that break payroll are monthly, quarterly and annual, and they only appear in the periods that contain them. - Every difference must be explained, not just tolerated. An unexplained variance of a few ringgit is a rule that is wrong, and rules do not stay small. A payroll migration is the one case where matching the old system exactly is the goal. Every unexplained difference in a parallel run is a defect you would otherwise find on payday. In most system migrations you cannot know the right answer in advance. You test against a specification, you accept some ambiguity, and you fix what users report afterwards. Payroll is different, and the difference is the whole opportunity. The old system already produces the answer, for every employee, every month. A new system can therefore be tested against truth rather than against a document. ## Why the first clean cycle proves very little Teams run one parallel cycle, find a handful of differences, fix them, and declare the migration ready. That is the most common way parallel running is done and it tests a fraction of the system. An ordinary month exercises basic pay, standard allowances, statutory contributions and normal deductions. It does not exercise a mid month joiner, a leaver with unused leave, a backdated increment, a bonus month with its own contribution treatment, a resignation with notice in lieu, an unpaid leave period, a change of contribution category, or the annual reconciliation of tax deducted. Those are the cases that produce payday failures, and each of them only appears in a period that contains one. ## Explain every difference, including the small ones The discipline that separates a real parallel run from a ceremonial one is that every difference is explained, at employee level, to the sen. A difference of a few ringgit is not noise. It is usually a rounding rule applied at a different point in the calculation, or a contribution derived from a slightly different base, or an allowance included in one system's definition of pay and excluded from the other's. Each of those is small on one employee and systematic across a workforce, and none of them stays small when it compounds over a year or reaches a statutory submission. The rule is not that differences must be zero. It is that every difference must have a named cause and a decision about which system is right, because sometimes the answer is that the old system has been wrong for years and somebody now has to deal with that. ## The old system is not automatically correct It is worth stating plainly, because parallel running surfaces it and teams are rarely prepared for it. A migration frequently finds that the incumbent system has been miscalculating something quietly. An allowance treated as non contributory that should have been contributory. Leave accrued on a basis that does not match the employment terms. A statutory rate that was updated late. These are not comfortable discoveries and they do not stop being true if the project ignores them. Finding them during a parallel run, where there is time and no payday pressure, is considerably better than finding them during an audit or a statutory review. ## How many cycles is enough The honest answer is: enough to have seen every category of event at least once, which is a property of the workforce rather than a number of months. For an organisation with stable headcount and simple terms, that may be two cycles plus a deliberately constructed set of cases run through both systems. For one with high turnover, shift allowances, multiple contribution categories, and a bonus cycle, it means covering the periods where those things happen, including the annual ones. The question to ask before cutting parallel running short is not whether the team is confident. It is which categories of employee event have not yet been proven, and what happens on the payday when one of them occurs. Share Subscribe Get new field notes when we publish them [Enter email](https://idataraya.com/contact/) ## Related content [Capability Payroll and HR Systems Read](https://idataraya.com/capabilities/payroll-and-hr/) [Field note Most payroll errors are entered, not calculated Read](https://idataraya.com/insights/payroll-errors-are-entered/) [Field note Automating a step nobody was waiting on Read](https://idataraya.com/insights/automating-the-wrong-step/) [Field note If nobody can check the answer, it cannot go into production Read](https://idataraya.com/insights/checkable-answers/) [Field note Test on the phones your staff actually carry Read](https://idataraya.com/insights/test-on-real-phones/) [Field note The warehouse is rarely the problem: where reporting actually breaks Read](https://idataraya.com/insights/where-reporting-breaks/) [Field note Integration is not the plumbing, it is the building Read](https://idataraya.com/insights/integration-is-the-building/) [Field note Two people, two numbers, and the end of a dashboard Read](https://idataraya.com/insights/two-people-two-numbers/) [Field note Rare releases are large releases Read](https://idataraya.com/insights/rare-releases-are-large/) --- --- title: "Most payroll errors are entered, not calculated | idataraya" description: "The engine rarely computes the wrong figure. It is given the wrong input, because a shift, a leave day or a change of terms was transcribed between two systems that never spoke." url: "https://idataraya.com/insights/payroll-errors-are-entered/" --- Systems # Most payroll errors are entered, not calculated By Amirul Hakim, Goh Wen Jie and Vasanthi Muthu for idataraya Field note 30 April 2026 5 minute read ![Someone typing at an office keyboard](https://idataraya.com/landing-v2/insights/payroll-errors-are-entered.jpg) The engine rarely computes the wrong figure. It is given the wrong input, because a shift, a leave day or a change of terms was transcribed between two systems that never spoke. When an employee is paid the wrong amount, the conversation is about payroll. The investigation almost always ends somewhere else. A shift that was worked and not submitted. Leave approved in a chat message and never entered. An increment effective from the first of the month, processed on the ninth. A transfer between cost centres that changed an allowance nobody remembered was attached to the old one. Payroll is blamed for a number it calculated correctly from information it was handed by four other processes. ## The inputs arrive from everywhere A monthly payroll for an operations business consumes attendance and shift data, overtime claims, leave balances and absences, claims and reimbursements, contractual changes, joiners and leavers, and any deductions arranged during the month. Those originate with supervisors, site managers, the employee, HR, and sometimes a spreadsheet maintained by one person who understands the allowance structure. Each handover is an opportunity for something to be late, incomplete, or expressed in a way the next step interprets differently. The payroll engine sits at the end of that chain and computes faithfully from whatever reached it. > Payroll is blamed for a number it calculated correctly from information it was handed by four other processes. ## The cut off is the real control Most organisations have a payroll cut off, and most treat it as an administrative deadline rather than as a control point. What matters is not that the date exists but what happens to items that arrive after it, and whether anyone can see what was missing before the run rather than after it. An overtime claim submitted two days late is not an exception to be processed next month. It is a payment an employee expected and will not receive, and they will find out on payday. A completeness check before the run, showing which sites have not submitted attendance, which approvals are outstanding, and which employees have no time recorded at all, converts a large class of payday problems into a Tuesday afternoon problem. ## Stop transcribing between systems The durable fix is to remove the transcription rather than to check it more carefully. Where attendance is captured on a device or a roster, payroll should read it directly rather than receive an export. Where leave is approved in a workflow, the balance and the absence should be the same record payroll consumes. Where a contractual change is made, its effective date should drive the calculation rather than a person remembering to apply it in the right month. Every one of those removes a step where a human converts information from one shape into another under time pressure, which is the only place these errors have ever come from. ## What good looks like on payday The measure worth tracking is not payroll accuracy in percentage terms, which is always high and always reassuring. It is the number of off cycle corrections made after each run, and the reason for each. Corrections caused by genuinely late events are unavoidable. Corrections caused by an input that existed on time and did not reach payroll are a measurement of the gap between systems, and that number can be driven to almost nothing. When it is, the payroll team stops spending the week after payday on repairs and the month becomes a run rather than a recovery. Share Subscribe Get new field notes when we publish them [Enter email](https://idataraya.com/contact/) ## Related content [Capability Payroll and HR Systems Read](https://idataraya.com/capabilities/payroll-and-hr/) [Field note The workarounds are the requirements Read](https://idataraya.com/insights/workarounds-are-requirements/) [Field note The online store that sells what the counter already sold Read](https://idataraya.com/insights/online-store-oversell/) [Field note The same student, twice, and the fee nobody is chasing Read](https://idataraya.com/insights/duplicate-student-records/) [Field note The building outlives every system bought for it Read](https://idataraya.com/insights/building-outlives-its-systems/) [Field note Automating a step nobody was waiting on Read](https://idataraya.com/insights/automating-the-wrong-step/) [Field note If nobody can check the answer, it cannot go into production Read](https://idataraya.com/insights/checkable-answers/) [Field note Test on the phones your staff actually carry Read](https://idataraya.com/insights/test-on-real-phones/) [Field note The warehouse is rarely the problem: where reporting actually breaks Read](https://idataraya.com/insights/where-reporting-breaks/) --- --- title: "Automating a step nobody was waiting on | idataraya" description: "A pilot can be accurate, well received and change nothing, because the step it improved was not the constraint. Start at the queue and the question answers itself." url: "https://idataraya.com/insights/automating-the-wrong-step/" --- Applied AI # Automating a step nobody was waiting on By Hidayah Rusli, Chan Yew Fai and Mohan Elangovan for idataraya Field note 14 May 2026 6 minute read ![Products moving along a factory conveyor](https://idataraya.com/landing-v2/insights/automating-the-wrong-step.jpg) ## Key Takeaways Most disappointing AI pilots are not inaccurate. They automated a step that was not holding anything up. - A process improves only at its constraint. Speeding up any other step moves work into a queue rather than out of one. - The steps chosen for pilots are usually the ones that are easiest to model, which correlates with being well defined, which correlates with already being fast. - Find the constraint by looking for where work waits, not where people are busy. Those are different places and only the first one matters. A pilot can be accurate, well received and change nothing, because the step it improved was not the constraint. Start at the queue and the question answers itself. A team automates document classification in a claims process. Accuracy is high, the users like it, the demonstration goes well. Six months later the process handles the same volume in the same elapsed time as before. Nothing failed. Classification genuinely got faster. It simply was not the reason anything took as long as it did. Everyone agreed the pilot worked. The documents now arrive faster at a desk where they were already waiting three days. ## Processes improve at one place only This is not a claim about AI, it is a property of any process with a bottleneck. Throughput is set by the slowest step. Improving anything upstream of it increases the size of the queue in front of it. Improving anything downstream leaves that step idle more often. The constraint in a document heavy process is rarely the reading. It is usually a step that requires a decision from a specific person, an approval that batches, or an interaction with an external party whose response time you do not control. None of those are helped by faster classification, and all of them are harder to automate, which is exactly why the pilot chose classification. > Everyone agreed the pilot worked. The documents now arrive faster at a desk where they were already waiting three days. ## Why pilots land on the wrong step The selection is not careless. It follows a sensible logic that produces a poor result. Teams pick steps with clean inputs, high volume, and a measurable output, because those are the steps where a model can be built and evaluated. But a step with clean inputs and a measurable output is usually a step that is already well understood and reasonably efficient. The messy steps, where information is incomplete and judgement is required, are both where the time goes and where modelling is hard. So the pilot optimises the part of the process that was working, and reports a percentage improvement on a step whose duration was never the issue. ## Look for waiting, not for effort The diagnostic is to measure elapsed time rather than effort. For a sample of real cases, record when each step started and finished, and calculate the gap between one step ending and the next beginning. Effort tells you where people are busy. Waiting tells you where the process is slow. In most administrative processes the waiting dwarfs the effort, often by an order of magnitude, and it is concentrated in two or three places. Once you have that picture, the automation question changes shape. It stops being what could a model do here, and becomes what is this case waiting for, and can that wait be removed, shortened, or made unnecessary. ## Sometimes the answer is not a model This is the uncomfortable part. Having found the constraint honestly, the fix for it is frequently not applied AI at all. If cases wait for a weekly approval meeting, the fix is a delegation threshold. If they wait on a document from a third party, the fix is asking for it at the start rather than at the point it is needed. If they wait because one person is the only one who can decide, the fix is a second person or a clearer rule. Teams that are honest about this end up applying AI in fewer places and getting more from it, because when they do apply it, it is at a step that was actually holding the process up. The pilot that gets cancelled after the constraint analysis has usually paid for itself. Share Subscribe Get new field notes when we publish them [Enter email](https://idataraya.com/contact/) ## Related content [Capability Artificial Intelligence Read](https://idataraya.com/capabilities/artificial-intelligence/) [Field note If nobody can check the answer, it cannot go into production Read](https://idataraya.com/insights/checkable-answers/) [Field note Test on the phones your staff actually carry Read](https://idataraya.com/insights/test-on-real-phones/) [Field note The warehouse is rarely the problem: where reporting actually breaks Read](https://idataraya.com/insights/where-reporting-breaks/) [Field note Integration is not the plumbing, it is the building Read](https://idataraya.com/insights/integration-is-the-building/) [Field note Two people, two numbers, and the end of a dashboard Read](https://idataraya.com/insights/two-people-two-numbers/) [Field note Rare releases are large releases Read](https://idataraya.com/insights/rare-releases-are-large/) [Field note The third-year cloud bill Read](https://idataraya.com/insights/third-year-cloud-bill/) [Field note Controls that depend on discipline fail during busy weeks Read](https://idataraya.com/insights/controls-that-need-discipline/) --- --- title: "If nobody can check the answer, it cannot go into production | idataraya" description: "In regulated and public sector work, the audit trail is not paperwork around the model. It is the thing that decides whether the model is allowed to do the job at all." url: "https://idataraya.com/insights/checkable-answers/" --- Governance # If nobody can check the answer, it cannot go into production By Zarina Kadir, Lau Zhi Hao and Karthik Ramasamy for idataraya Field note 28 May 2026 6 minute read ![A person reviewing printed documents with a pen](https://idataraya.com/landing-v2/insights/checkable-answers.jpg) In regulated and public sector work, the audit trail is not paperwork around the model. It is the thing that decides whether the model is allowed to do the job at all. A model that performs well and cannot be checked is not a candidate for production in a regulated process. That is not a compliance opinion, it is an operational one: a decision nobody can review is a decision nobody can defend, correct, or learn from. The question a regulator asks is not whether the system was right. It is how you established that it was, on this case, on the day. ## Checkable is a property of the design Checkability is often treated as a reporting requirement bolted on at the end: log the inputs, log the outputs, keep them for seven years. That produces a large volume of evidence that answers almost no useful question. What makes a decision checkable is narrower. A reviewer needs to see what the system was given, which version of the logic acted on it, what it produced, what it relied on to produce that, and who could have intervened. The third and fourth of those are where most systems fall short, and they are the ones a person actually needs to form a view. A record showing that input A produced output B tells a reviewer what happened. It does not let them judge whether it should have. > The question a regulator asks is not whether the system was right. It is how you established that it was, on this case, on the day. ## The reviewer has to be able to disagree A review that can only confirm is not a review. If the only available action is to accept the system's output, the human in the loop is a formality, and everyone involved knows it within a fortnight. Meaningful review needs three things. The reviewer must see enough to form an independent view, not merely a summary that restates the conclusion. Overriding must be a normal, easy action rather than an escalation. And overrides must be recorded with a reason and looked at, because a pattern of overrides in one category is the earliest signal that the system is wrong about something. Systems that make overriding awkward get high agreement rates and learn nothing. ## Public sector work has an extra requirement Where a decision affects a citizen, there is usually a right to an explanation and a route to challenge it. That places a requirement on the system that has nothing to do with accuracy: the reason given to the affected person has to be the actual reason the decision was made. A post hoc explanation generated separately from the decision does not satisfy this, even if it sounds convincing, because it is a description of a decision rather than an account of one. This tends to push regulated implementations towards designs where the model narrows, ranks, or flags, and an accountable person decides. That is often read as timidity. It is usually just the shape that survives being challenged. ## What to settle before building Four questions, asked early, determine whether a system can be deployed at all, and they are cheap to answer at design and expensive to retrofit. Who is accountable for an individual decision, by name or by role. What that person must be able to see to accept or reject it. What the affected party is entitled to be told, and whether the system can produce that from the actual decision. And how long the whole record must be retrievable, in a form that can still be read when the model has been replaced twice. Answer those and the audit trail stops being paperwork around the model. It becomes the thing that lets the model be used. Share Subscribe Get new field notes when we publish them [Enter email](https://idataraya.com/contact/) ## Related content [Capability Artificial Intelligence Read](https://idataraya.com/capabilities/artificial-intelligence/) [Field note Audit evidence is a feature, not a report you run later Read](https://idataraya.com/insights/audit-evidence/) [Field note Whose records are they when the managing agent changes Read](https://idataraya.com/insights/whose-records-managing-agent/) [Field note Test on the phones your staff actually carry Read](https://idataraya.com/insights/test-on-real-phones/) [Field note The warehouse is rarely the problem: where reporting actually breaks Read](https://idataraya.com/insights/where-reporting-breaks/) [Field note Integration is not the plumbing, it is the building Read](https://idataraya.com/insights/integration-is-the-building/) [Field note Two people, two numbers, and the end of a dashboard Read](https://idataraya.com/insights/two-people-two-numbers/) [Field note Rare releases are large releases Read](https://idataraya.com/insights/rare-releases-are-large/) [Field note The third-year cloud bill Read](https://idataraya.com/insights/third-year-cloud-bill/) --- --- title: "Test on the phones your staff actually carry | idataraya" description: "Field fleets are older, cheaper and more varied than any test matrix assumes. The device that struggles is the one deciding whether the rollout succeeds." url: "https://idataraya.com/insights/test-on-real-phones/" --- Mobile # Test on the phones your staff actually carry By Firdaus Kamaruddin, Ho Sze Wei and Anitha Perumal for idataraya Field note 11 June 2026 5 minute read ![A hand holding a smartphone outdoors](https://idataraya.com/landing-v2/insights/test-on-real-phones.jpg) ## Key Takeaways A field application is judged by its worst experience, not its average one, and the worst experience is on a device nobody on the project owns. - Field devices are typically several years old, at the lower end of the market, low on storage, and running an operating system version the team stopped testing against. - The failures that stop a rollout are not crashes. They are slowness, battery drain, and a camera or scanner that takes three attempts in poor light. - Buy the two worst devices in the fleet and make them the development targets. Everything better than them takes care of itself. Field fleets are older, cheaper and more varied than any test matrix assumes. The device that struggles is the one deciding whether the rollout succeeds. A field application is demonstrated on the project manager's phone, developed on the engineers' phones, and tested on a rack of recent devices in a well lit office with strong wifi. It is then rolled out to drivers, technicians and enumerators carrying phones that are four years old, were inexpensive when new, have two gigabytes of free storage, and spend the day outdoors on mobile data. The application does not fail. It just becomes unpleasant enough to avoid, which produces the same outcome more slowly. ## What the fleet is really made of Where devices are personally owned, which is common for contractors and gig workers, the fleet is whatever the market sold cheaply three or four years ago, in a wide spread of makes, running a range of operating system versions, some of which no longer receive updates. Where devices are company issued, they were bought at the lowest acceptable specification, in one purchase, and they have aged together. That is better for consistency and worse for capability, because the whole fleet is simultaneously old. Either way the median field device is nothing like a development device, and the tenth percentile device is where the rollout will be decided. ## The failures are not crashes Crashes get reported and fixed. The problems that quietly kill adoption do not look like defects. A screen that takes four seconds to appear, which is fine once and unbearable thirty times a shift. Battery drain that leaves the device flat before the run ends, which is not a software bug in anyone's tracker and is a complete blocker for the driver. A camera capture that needs three attempts in a dim stairwell. An application that is evicted from memory when the user takes a call, losing what they had entered. None of those appear on a modern device. All of them are ordinary on an old one. ## Make the worst device the target The practical answer is unglamorous. Establish what is actually in the fleet, by asking, and buy two of the worst ones. Not one, because a single unit becomes unavailable at the wrong moment. Then make those the development and acceptance targets. A feature is done when it is comfortable on that device, not when it works on it. Performance budgets are set from it. Demonstrations are given on it. This is a cheap purchase that changes what the team notices day to day, which is the only reliable way to change what gets built. Everything faster than the target device is handled automatically, and nothing needs a separate optimisation phase later. ## Test where the work happens The other half is the environment. Office wifi and a desk are not the conditions the application runs in. The conditions are a basement car park with no signal, bright afternoon sun on a screen at low brightness, one hand holding a parcel, gloves, rain, and a network that is present but slow rather than cleanly absent. That last one is the hardest and the most common, because software handles no connection far better than it handles a bad one. Half a day spent following a real route with a real device will produce a more useful defect list than a fortnight of testing in the office, and it will contain things nobody would have thought to write down. Share Subscribe Get new field notes when we publish them [Enter email](https://idataraya.com/contact/) ## Related content [Capability Mobile Applications Read](https://idataraya.com/capabilities/mobile-applications/) [Field note The warehouse is rarely the problem: where reporting actually breaks Read](https://idataraya.com/insights/where-reporting-breaks/) [Field note Integration is not the plumbing, it is the building Read](https://idataraya.com/insights/integration-is-the-building/) [Field note Two people, two numbers, and the end of a dashboard Read](https://idataraya.com/insights/two-people-two-numbers/) [Field note Rare releases are large releases Read](https://idataraya.com/insights/rare-releases-are-large/) [Field note The third-year cloud bill Read](https://idataraya.com/insights/third-year-cloud-bill/) [Field note Controls that depend on discipline fail during busy weeks Read](https://idataraya.com/insights/controls-that-need-discipline/) [Field note Account recovery is usually the softest way in Read](https://idataraya.com/insights/account-recovery-soft-way-in/) [Field note Degrading well beats recovering fast Read](https://idataraya.com/insights/degrading-well/) --- --- title: "The warehouse is rarely the problem: where reporting actually breaks | idataraya" description: "Reporting usually fails upstream, in a pipeline that completed against a partial source or a field that means two different things. The dashboard is where you notice, not where it went wrong." url: "https://idataraya.com/insights/where-reporting-breaks/" --- Data # The warehouse is rarely the problem: where reporting actually breaks By Norsyafiqah Ismail, Tee Chong Han, Dinesh Kanagaraj and Azlan Mustapha for idataraya Field note 2 July 2026 7 minute read ![An analytics dashboard on a screen](https://idataraya.com/landing-v2/insights/where-reporting-breaks.jpg) Reporting usually fails upstream, in a pipeline that completed against a partial source or a field that means two different things. The dashboard is where you notice, not where it went wrong. When numbers are wrong, the platform gets rebuilt. A new warehouse, a new modelling layer, a new visualisation tool, and eighteen months later the same complaint returns in a nicer interface. That happens because the diagnosis was made where the symptom appeared. The dashboard is where a wrong number becomes visible. It is almost never where it became wrong. ## Failure one: the pipeline that succeeded The most damaging failure is not a job that fails. A failed job raises an alert and somebody reruns it. The damaging case is a job that runs on schedule, reads a source that was only partially written, loads what it found, and reports success. The dashboard updates. The figure is low. Nobody knows, because every indicator says the load completed normally. The pipeline did not fail. It succeeded, on incomplete data, and reported success, which is considerably worse. The defence is a completeness check rather than a success check: does the volume loaded sit in a plausible range against recent days, does the control total from the source match what arrived, is every expected partition present. A pipeline should be able to refuse to publish, and most cannot. > The pipeline did not fail. It succeeded, on incomplete data, and reported success, which is considerably worse. ## Failure two: the field that means two things A field named status exists in the order system and the delivery system. They are joined on the assumption that they mean the same thing. In the order system it means the state of the payment. In the delivery system it means the state of the parcel. Nothing breaks. Every row joins. The resulting report answers a question nobody asked, and it answers it consistently, which is why it survives review. This is the failure that most resists technical solutions, because there is nothing malformed to detect. It is caught by definitions written down and owned by someone in the business, not by validation. ## Failure three: the source changed and nobody said An operational system is upgraded. A field is repurposed, a code list gains a value, a timestamp changes from local time to a standard one, an identifier gains a prefix. None of that is unreasonable and none of it is announced, because the operational team does not have a list of everything downstream that reads their tables. The pipeline keeps running. The numbers shift, slightly, from a date nobody notices for months. The mitigation is boring and effective: know which downstream reports depend on which source fields, and monitor distributions rather than only schemas. A code that has never appeared before, or a sudden change in the shape of a column, is a stronger early warning than any change control process that relies on people remembering. ## Failure four: the number that was right and is not now Records change after they are loaded. An order is cancelled, a payment is reversed, a claim is reassessed, a customer record is merged. If reporting is built on a snapshot taken nightly, a figure that was correct on Tuesday becomes incorrect on Wednesday, and the report from Tuesday still says what it said. Both are defensible individually and neither is explicable to a manager who printed one. This is a modelling decision rather than a defect, and the requirement is to make it explicit: is this report as at the date it covers, or as at today. Reports that do not answer that question generate the arguments that eventually get blamed on the platform. ## Fix the pipeline before you replace the warehouse A warehouse migration is a large, visible, fundable project. Completeness checks, definitions, and dependency mapping are small, dull, and unfundable, which is a reasonable description of why the first happens and the second does not. But almost every reporting complaint traces to one of the four failures above, and none of them are fixed by a new platform. They travel with the data into whatever is built next. The useful test before approving a rebuild: take the three numbers people currently distrust and trace each one back to its source. If the reason is upstream, and it usually is, the rebuild will reproduce it faithfully in a better looking chart. Share Subscribe Get new field notes when we publish them [Enter email](https://idataraya.com/contact/) ## Related content [Capability Digital and Technology Read](https://idataraya.com/capabilities/digital-and-technology/) [Capability Data and Analytics Read](https://idataraya.com/capabilities/data-and-analytics/) [Field note Integration is not the plumbing, it is the building Read](https://idataraya.com/insights/integration-is-the-building/) [Field note Two people, two numbers, and the end of a dashboard Read](https://idataraya.com/insights/two-people-two-numbers/) [Field note Rare releases are large releases Read](https://idataraya.com/insights/rare-releases-are-large/) [Field note The third-year cloud bill Read](https://idataraya.com/insights/third-year-cloud-bill/) [Field note Controls that depend on discipline fail during busy weeks Read](https://idataraya.com/insights/controls-that-need-discipline/) [Field note Account recovery is usually the softest way in Read](https://idataraya.com/insights/account-recovery-soft-way-in/) [Field note Degrading well beats recovering fast Read](https://idataraya.com/insights/degrading-well/) --- --- title: "Integration is not the plumbing, it is the building | idataraya" description: "It is routinely scoped as the small part around the edges of a programme and routinely turns out to be the largest, slowest part of it. Estimating it honestly changes what a plan is worth." url: "https://idataraya.com/insights/integration-is-the-building/" --- Engineering # Integration is not the plumbing, it is the building By Khairul Anwar, Phang Mei Yee and Rohan Pillai for idataraya Field note 23 July 2026 6 minute read ![A steel structural frame under construction](https://idataraya.com/landing-v2/insights/integration-is-the-building.jpg) ## Key Takeaways Integration is underestimated for a structural reason: the estimate is made by the party that controls the least of the work. - The technical connection is a small fraction of the effort. The rest is agreeing meaning, handling failure, and waiting on parties with their own priorities. - Every integration has a counterparty whose availability, release calendar and change control you do not govern. - Estimating honestly means naming the dependencies as dependencies in the plan, rather than as tasks your team can complete. It is routinely scoped as the small part around the edges of a programme and routinely turns out to be the largest, slowest part of it. Estimating it honestly changes what a plan is worth. A programme plan lists the modules to be built, the data to be migrated, the testing, the training, the cutover. Somewhere near the bottom there is a line called integration, sized as a fraction of the whole. At the end of the programme, integration is what everyone is still working on, and it is what the go live date moved for. ## What the line item actually contains Connecting two systems technically is usually straightforward and is the part people picture when they estimate. It is a minority of the work. The rest is establishing what each side means by the fields being exchanged, and discovering that the two definitions differ in ways nobody documented. It is deciding what happens when a message is rejected, duplicated, delayed, or arrives out of order, and who is responsible for noticing. It is agreeing how both sides prove they hold the same state after a disagreement. It is testing against an environment that is shared, unstable, and refreshed on somebody else's schedule. And it is waiting: for access, for credentials, for a counterparty's change window, for a specification clarification from a team with its own backlog. ## You are estimating someone else's work This is the structural reason integration estimates are wrong rather than merely optimistic. For every other line in a plan, the estimate covers work your team performs. For integration, a substantial portion of the elapsed time is consumed by an organisation you do not control, with its own release calendar, its own change advisory process, its own view of how urgent your programme is, and its own staff turnover. A three day task that requires a counterparty to open a firewall rule is not a three day task. It is a three day task plus their queue, and their queue is not visible from your plan. ## Estimate the dependencies, not the effort The correction is not to inflate the number, which is what usually happens and which nobody believes. It is to list, explicitly, every dependency on a party outside the programme, with what is needed, from whom, and by when. Then to treat each of those as a plan item with an owner and a date, tracked as visibly as the build work. That does two useful things. It makes the true critical path visible early, which is usually a sequence of external dependencies rather than a sequence of development tasks. And it gives sponsors something they can actually act on, because a sponsor cannot make development faster but can frequently make another department answer. ## Start at the connection, not at the features The strongest practical move is to reverse the usual order: prove the integration first, on a trivial case, end to end, in the real environment, before building the features that depend on it. One transaction, through the actual interface, with the actual credentials, in the actual environment, reconciled at both ends. It looks like a small deliverable and it retires most of the programme's real risk, because everything that would have surprised you in month eight surprises you in month one instead, when there is still time. Programmes that do this rarely have an integration problem at the end. They had it at the start, which is where it is cheap. Share Subscribe Get new field notes when we publish them [Enter email](https://idataraya.com/contact/) ## Related content [Capability Digital and Technology Read](https://idataraya.com/capabilities/digital-and-technology/) [Field note Rare releases are large releases Read](https://idataraya.com/insights/rare-releases-are-large/) [Field note The timeout with an unknown outcome Read](https://idataraya.com/insights/timeout-unknown-outcome/) [Field note Two people, two numbers, and the end of a dashboard Read](https://idataraya.com/insights/two-people-two-numbers/) [Field note The third-year cloud bill Read](https://idataraya.com/insights/third-year-cloud-bill/) [Field note Controls that depend on discipline fail during busy weeks Read](https://idataraya.com/insights/controls-that-need-discipline/) [Field note Account recovery is usually the softest way in Read](https://idataraya.com/insights/account-recovery-soft-way-in/) [Field note Degrading well beats recovering fast Read](https://idataraya.com/insights/degrading-well/) [Field note Taking over a system you did not build: the first ninety days Read](https://idataraya.com/insights/inheriting-a-system/) --- --- title: "Two people, two numbers, and the end of a dashboard | idataraya" description: "Trust in reporting is lost the first time two colleagues find different answers in it. Settling definitions before building is cheaper than rebuilding credibility afterwards." url: "https://idataraya.com/insights/two-people-two-numbers/" --- Analytics # Two people, two numbers, and the end of a dashboard By Suriani Osman, Leong Chun Kit and Bhavani Sekar for idataraya Field note 6 August 2026 5 minute read ![Two colleagues discussing work at a laptop](https://idataraya.com/landing-v2/insights/two-people-two-numbers.jpg) Trust in reporting is lost the first time two colleagues find different answers in it. Settling definitions before building is cheaper than rebuilding credibility afterwards. A sales lead and a finance manager both open the revenue dashboard before a meeting. One has a figure for the month. The other has a different one. The meeting spends its first fifteen minutes on which is correct and its remaining time on something else entirely. Neither of them opens the dashboard with confidence again, and within a quarter both have gone back to their own spreadsheets. ## Usually both numbers are right The instinct is that one of them is wrong, and it is worth resisting because it sends the investigation in an unproductive direction. In most cases both figures are correct answers to slightly different questions. One counts revenue when the order was placed, the other when it was invoiced. One includes intercompany, the other does not. One counts the cancelled order that was cancelled after month end, the other has already removed it. One is in the currency of the transaction, the other converted at a rate fixed on a different date. Both numbers were right. That is the problem, and it cannot be fixed in the reporting tool. > Both numbers were right. That is the problem, and it cannot be fixed in the reporting tool. ## Definitions are a business decision The reason this persists is that settling the definition requires someone with authority to say what the organisation means by revenue, or by an active customer, or by an open case, and to accept that some existing reports will change. That is uncomfortable, so it is usually delegated to the analytics team, who cannot make it because it is not their decision. They resolve it by building what each requester asked for, which is professional and produces exactly the situation described above. The prerequisite for a trusted metric is not a data model. It is a named owner who decides what it means and is accountable for that meaning being consistent. ## A small number of definitions, written down The practical instrument is unimpressive: a short list of the metrics the organisation actually runs on, each with a plain language definition, an owner, what is included and excluded, and the date from which the definition applies. Short matters. A catalogue of four hundred definitions is a documentation project that nobody reads. Fifteen to thirty metrics covers what is argued about in most organisations, and those are the ones that need to be settled. Then the reporting layer computes each metric in one place, and every report that uses it reads that one place rather than reimplementing the logic. A metric with two implementations will eventually have two values, regardless of how carefully both were written. ## Credibility is the actual asset The cost of the incident above is not the fifteen minutes. It is that two senior people learned the dashboard cannot be relied on in front of others, and that lesson does not get unlearned by fixing the discrepancy. Recovering it takes longer than establishing it, because the next few figures are checked against a spreadsheet before being used, and every small difference confirms the original judgement. This is why the definitional work belongs at the start, when it looks like an unnecessary delay before the interesting part. It is the cheapest it will ever be, and it is the only phase where nobody has yet been embarrassed by the output. Share Subscribe Get new field notes when we publish them [Enter email](https://idataraya.com/contact/) ## Related content [Capability Data and Analytics Read](https://idataraya.com/capabilities/data-and-analytics/) [Field note Rare releases are large releases Read](https://idataraya.com/insights/rare-releases-are-large/) [Field note The third-year cloud bill Read](https://idataraya.com/insights/third-year-cloud-bill/) [Field note Controls that depend on discipline fail during busy weeks Read](https://idataraya.com/insights/controls-that-need-discipline/) [Field note Account recovery is usually the softest way in Read](https://idataraya.com/insights/account-recovery-soft-way-in/) [Field note Degrading well beats recovering fast Read](https://idataraya.com/insights/degrading-well/) [Field note Taking over a system you did not build: the first ninety days Read](https://idataraya.com/insights/inheriting-a-system/) [Field note What breaks in a bank integration, and roughly when Read](https://idataraya.com/insights/what-breaks-in-bank-integrations/) [Field note We build, and we maintain: inside the idataraya engagement model Read](https://idataraya.com/insights/the-engagement-model/) --- --- title: "Rare releases are large releases | idataraya" description: "A deployment process that needs a meeting produces batched change, and batched change fails in ways nobody can isolate. Making releases boring is a reliability decision, not a convenience one." url: "https://idataraya.com/insights/rare-releases-are-large/" --- Engineering # Rare releases are large releases By Adib Rahim, Toh Wei Lun and Nirmala Devi for idataraya Field note 27 August 2026 5 minute read ![An engineer working in a server room](https://idataraya.com/landing-v2/insights/rare-releases-are-large.jpg) ## Key Takeaways Release frequency and release risk move in opposite directions, which is the reverse of how most change processes assume they work. - Infrequent releases accumulate change, and a release containing forty changes that misbehaves gives you forty suspects. - Long gaps between deployments also mean the deployment path itself is rarely exercised, so the mechanism is untested at the moment it matters most. - Reducing batch size is the single change that most improves diagnosis, because a release with one change has one suspect. A deployment process that needs a meeting produces batched change, and batched change fails in ways nobody can isolate. Making releases boring is a reliability decision, not a convenience one. An organisation nervous about production stability responds by making releases harder: a change advisory meeting, a freeze period, a monthly window, sign offs from several parties. Each of those measures is individually sensible and their combined effect is to guarantee that every release is large, because a month of work goes out at once. ## Batch size decides diagnosis When a release containing one change causes a problem, the cause is known immediately. When a release containing forty changes causes a problem, there are forty candidates, they interact, and the investigation takes hours during which the system is misbehaving. The rollback decision is worse. Rolling back one change costs that change. Rolling back a monthly release costs everything in it, including thirty nine changes that were fine and several that other teams are depending on. So the process introduced to reduce risk has made the consequence of any failure substantially larger and considerably harder to reason about. ## The path itself goes stale There is a second effect that is less obvious and often more damaging. A deployment path used once a month is a path nobody has recent experience with. The credentials expired and nobody noticed. A dependency in the pipeline was updated. The person who normally runs it is on leave and the runbook is a year old. The rollback procedure has never actually been executed against production, only described. Frequent deployment keeps the mechanism warm. It is used often enough that breakage is found on an ordinary Tuesday rather than during the one release that had to go out. ## What makes a release boring Boring is the goal and it has recognisable properties. The same automated path every time, with no manual steps that vary by release. Small changes, deployed as they are ready rather than gathered. A verified rollback that has been performed recently rather than documented. Monitoring that tells you the deployment was healthy without someone watching a screen. Where a change is genuinely risky, separate the deployment from the release: put the code out inactive and turn it on separately. That converts a risky deployment into an ordinary one plus a reversible switch, which is a far better thing to hold a meeting about. ## Where freezes still make sense This is not an argument against control. Some periods genuinely warrant a freeze: a peak trading week, a statutory submission window, the days around a major event where the cost of any disruption is disproportionate. The distinction is that a freeze should be a deliberate, bounded exception with a stated reason and an end date, not the operating norm. A permanent freeze punctuated by monthly windows is not caution. It is a process that has chosen large releases and has not noticed. Share Subscribe Get new field notes when we publish them [Enter email](https://idataraya.com/contact/) ## Related content [Capability Cloud and Infrastructure Read](https://idataraya.com/capabilities/cloud-and-infrastructure/) [Field note The timeout with an unknown outcome Read](https://idataraya.com/insights/timeout-unknown-outcome/) [Field note Integration is not the plumbing, it is the building Read](https://idataraya.com/insights/integration-is-the-building/) [Field note The third-year cloud bill Read](https://idataraya.com/insights/third-year-cloud-bill/) [Field note Controls that depend on discipline fail during busy weeks Read](https://idataraya.com/insights/controls-that-need-discipline/) [Field note Account recovery is usually the softest way in Read](https://idataraya.com/insights/account-recovery-soft-way-in/) [Field note Degrading well beats recovering fast Read](https://idataraya.com/insights/degrading-well/) [Field note Taking over a system you did not build: the first ninety days Read](https://idataraya.com/insights/inheriting-a-system/) [Field note What breaks in a bank integration, and roughly when Read](https://idataraya.com/insights/what-breaks-in-bank-integrations/) --- --- title: "The third-year cloud bill | idataraya" description: "Infrastructure sized at launch and never revisited grows quietly around the edges. By the time anyone asks, nobody remembers what half of it is for." url: "https://idataraya.com/insights/third-year-cloud-bill/" --- Operations # The third-year cloud bill By Hasrul Fadzil, Chew Sook Mun and Ashwin Raghavan for idataraya Field note 4 September 2026 5 minute read ![Server racks in a data centre](https://idataraya.com/landing-v2/insights/third-year-cloud-bill.jpg) Infrastructure sized at launch and never revisited grows quietly around the edges. By the time anyone asks, nobody remembers what half of it is for. The cloud bill is examined properly at two moments: when the platform is first sized, and roughly three years later when somebody in finance asks why it has doubled while the business has not. Between those two moments it grows in small increments, each of which was justified at the time and none of which was revisited. ## How the growth happens The pattern is consistent. An environment is created for a project and never removed, because removing it requires being certain nobody needs it. A database is scaled up during an incident and never scaled back, because the incident ended and the setting was not the point. Snapshots and backups accumulate on a retention policy that was set as a default and never matched to a real requirement. Logs are retained at full fidelity for years because storage seemed cheap when the volume was a tenth of what it is now. None of these are mistakes. Each was the right call in the moment. What is missing is the second half of each decision, the part where somebody comes back and asks whether it still applies. > Nobody can switch it off, because nobody can prove it does nothing. That is the actual problem, and it is a record keeping problem. ## The unattributed half By the third year the harder problem is not the amount, it is that a substantial portion of the bill cannot be attributed to anything. Resources created by people who have left, for projects that were cancelled, in accounts nobody owns, with names that meant something to one person once. Nobody can switch it off, because nobody can prove it does nothing. That is the actual problem, and it is a record keeping problem rather than a financial one. Tagging solves it and is almost never applied retrospectively with any success, because the information needed to tag a two year old resource correctly no longer exists. ## Optimisation is the smaller half The usual response is a cost optimisation exercise: rightsizing, reserved capacity, storage tiering. Those are worthwhile and they address the part of the bill that is understood. They do not address the part that is unattributed, which is frequently the larger share of the surprise. Buying reserved capacity for workloads nobody has justified locks in the spend rather than reducing it, and it is the most common way an optimisation exercise makes the third year problem permanent. Attribution before optimisation, always. You cannot rightsize something whose purpose is unknown, and committing to it for three years is worse than paying the on demand rate while you find out. ## The habit that prevents it Preventing this is not a tooling question. It is one recurring review with a specific agenda: what is running, who owns it, what would break if it stopped, and when that was last true. Run quarterly on a platform of ordinary size, it takes a short session and it keeps every resource attached to a person and a purpose. Run for the first time in year three, it is an archaeology project with a budget attached. The infrastructure did not get expensive. It got anonymous, and the cost followed. Share Subscribe Get new field notes when we publish them [Enter email](https://idataraya.com/contact/) ## Related content [Capability Cloud and Infrastructure Read](https://idataraya.com/capabilities/cloud-and-infrastructure/) [Field note Taking over a system you did not build: the first ninety days Read](https://idataraya.com/insights/inheriting-a-system/) [Field note An untested restore is a belief, not a backup Read](https://idataraya.com/insights/untested-restore/) [Field note One catalogue, or the argument you have every month Read](https://idataraya.com/insights/one-catalogue/) [Field note Your terminal estate is a logistics business. Run it like one. Read](https://idataraya.com/insights/provisioning-a-terminal-fleet/) [Field note Seasonal hiring is a software requirement Read](https://idataraya.com/insights/seasonal-hiring-software/) [Field note Arrears are a process, and the process needs a trail Read](https://idataraya.com/insights/arrears-need-a-trail/) [Field note Controls that depend on discipline fail during busy weeks Read](https://idataraya.com/insights/controls-that-need-discipline/) [Field note Account recovery is usually the softest way in Read](https://idataraya.com/insights/account-recovery-soft-way-in/) --- --- title: "Controls that depend on discipline fail during busy weeks | idataraya" description: "A policy asks people to behave a certain way under pressure. A system that enforces the same rule is the only version of the control that survives the month it matters." url: "https://idataraya.com/insights/controls-that-need-discipline/" --- Security # Controls that depend on discipline fail during busy weeks By Rosli Manaf, Ooi Cheng Hoe and Sumathi Balan for idataraya Field note 18 September 2026 5 minute read ![A busy commercial kitchen during service](https://idataraya.com/landing-v2/insights/controls-that-need-discipline.jpg) ## Key Takeaways Every control that requires a person to choose the slower path is a control that is strongest when it is least needed. - Policy controls degrade exactly in proportion to workload, so they are weakest during the periods with the highest volume and the highest exposure. - The workaround is usually invented by a competent person solving a real problem, which is why it spreads and why nobody reports it. - A control implemented as a system behaviour costs more to build once and does not need to be re-established after every busy period. A policy asks people to behave a certain way under pressure. A system that enforces the same rule is the only version of the control that survives the month it matters. A retail group has a policy that discounts above a threshold require supervisor approval. During an ordinary week it is followed. During the week before a major festival, with queues out the door and half the counter staff on their second shift, it is followed less, and by the end of the week a practice has emerged where the supervisor's code is shared so the queue keeps moving. Nobody decided that. It emerged, for good reasons, under pressure, and it will not be reversed when the pressure ends because by then it is simply how the counter works. ## The inverse relationship Controls that depend on people choosing the slower path have a property worth stating plainly: their effectiveness is inversely related to workload. Quiet week, low volume, low exposure, control fully observed. Peak week, high volume, high exposure, control observed least. The control is at its weakest precisely when the amount at risk is greatest, which is the opposite of what the control was designed to achieve. The control did not fail because someone was careless. It failed because it asked for care at the one moment there was none available. > The control did not fail because someone was careless. It failed because it asked for care at the one moment there was none available. ## Workarounds are competent, which is the problem The shared supervisor code is not laziness. It is a reasonable response by a capable person to an instruction that conflicts with the more urgent instruction to serve the queue. That is what makes it durable. It solves a genuine problem, it is taught to new staff as practical knowledge, and it is never reported because everyone involved understands it as helpfulness rather than as a breach. It is also invisible to any audit that samples records, because the records show approvals. They just do not show who actually gave them. ## What enforcement looks like at the same counter The same control implemented in the system behaves differently. The discount above the threshold cannot be applied without a second, distinct credential, and applying it takes the same few seconds every time regardless of how busy the shop is. There is no faster path to discover, so none is discovered. The record of who approved it is a fact rather than an assertion. And the control does not need re-establishing after every peak period, because it never eroded. The cost is real: enforcement is more work to build, and it removes some flexibility that occasionally would have been useful. That trade is the decision, and it should be made deliberately rather than by writing a policy and hoping. ## Which controls deserve enforcement Not everything can or should be enforced by a system. The test is what happens to the control under maximum pressure, and how much is exposed when it stops being observed. A control that protects a material amount, that is exercised frequently, and that has an obvious faster path is a candidate for enforcement. A control exercised rarely, under supervision, where the faster path is not appreciably faster, is fine as policy. The useful exercise is to take the controls the organisation relies on and ask, for each, what the workaround would be during the busiest week of the year. The ones with an easy answer are the ones that are already not working. Share Subscribe Get new field notes when we publish them [Enter email](https://idataraya.com/contact/) ## Related content [Capability Security Read](https://idataraya.com/capabilities/security/) [Capability Risk Management and Compliance Read](https://idataraya.com/capabilities/risk-management-and-compliance/) [Field note Account recovery is usually the softest way in Read](https://idataraya.com/insights/account-recovery-soft-way-in/) [Field note Degrading well beats recovering fast Read](https://idataraya.com/insights/degrading-well/) [Field note Taking over a system you did not build: the first ninety days Read](https://idataraya.com/insights/inheriting-a-system/) [Field note What breaks in a bank integration, and roughly when Read](https://idataraya.com/insights/what-breaks-in-bank-integrations/) [Field note We build, and we maintain: inside the idataraya engagement model Read](https://idataraya.com/insights/the-engagement-model/) [Field note The asasii suite: production engines we compose every system from Read](https://idataraya.com/insights/the-asasii-suite/) [Field note Settlement files never agree on the first pass Read](https://idataraya.com/insights/settlement-files/) --- --- title: "Account recovery is usually the softest way in | idataraya" description: "Authentication gets the attention and the budget. The reset flow beside it is often the part that decides how hard the system actually is to enter." url: "https://idataraya.com/insights/account-recovery-soft-way-in/" --- Security # Account recovery is usually the softest way in By Nabilah Zulkarnain, Kwan Li Fen and Deepak Nair for idataraya Field note 1 October 2026 6 minute read ![A lock on a door](https://idataraya.com/landing-v2/insights/account-recovery-soft-way-in.jpg) Authentication gets the attention and the budget. The reset flow beside it is often the part that decides how hard the system actually is to enter. A system is specified with strong authentication: a second factor, sensible session handling, rate limiting, a password policy that someone argued about at length. Beside it sits the recovery flow, which was specified in an afternoon because it is not really a security feature, it is a support feature. It is also, in most systems, the shortest path in. An attacker does not have to defeat the front door if the process for people who lost their key will simply issue another one. ## Recovery is authentication with worse inputs This is the framing that makes the design tractable. Recovery is not a support process that happens to grant access. It is authentication, performed for someone who cannot present the normal credential, using weaker evidence. Once framed that way, the obvious question is what evidence is actually being accepted, and whether it is available to anybody other than the account holder. The usual answers are uncomfortable. A registered email address, which may itself have been compromised, and frequently by the same route. A mobile number, which can be ported or reassigned. Date of birth, identity card number, mother's maiden name, and the last transaction amount, all of which are either public, guessable, or already in the possession of someone who has been reading the account holder's post. > An attacker does not have to defeat the front door if the process for people who lost their key will simply issue another one. ## The assisted channel is the weakest link Self service recovery can at least be made consistent. The channel that most often fails is the human one, where a caller cannot complete the automated flow and speaks to an agent. The agent has a script, a screen full of account information, a queue, and a performance measure that rewards resolving the call. The caller is upset, plausible, and in a hurry. Every part of that situation pushes towards helping. Attacks on this channel do not need technical sophistication. They need a plausible story, some publicly available detail, and the willingness to call several times until an agent who wants to help picks up. Any single agent behaving reasonably can undo a control the whole system depends on. ## Design the flow, then design the exception The strongest practical measures are unremarkable individually. Recovery evidence should be something the organisation issued or observed rather than something a person knows, since knowledge is the category most easily acquired by someone else. A recovery in progress should notify the account holder through every channel on file at the moment it starts, not after it completes, because the notification is the only defence when the evidence has already been defeated. Any change of contact details should be a security event in its own right, with a delay and a notification to the previous address, since changing where notifications go is the first move in most account takeovers. For the assisted channel, the agent should not be the decision. The system should decide, from evidence the agent captures, with the outcome and the reason recorded. That protects the agent as much as the account holder. ## Test it the way it will be attacked Recovery flows are rarely tested adversarially, because testing them looks like testing a support process. The productive exercise is to take a real account with the account holder's cooperation, gather only what could be found publicly or bought cheaply, and attempt recovery through every available channel. Self service, the call centre, the branch or counter if one exists, and any partner channel that can act on the account. Organisations that run this are usually surprised by which channel succeeds, and it is almost never the one that received the security review. Share Subscribe Get new field notes when we publish them [Enter email](https://idataraya.com/contact/) ## Related content [Capability Security Read](https://idataraya.com/capabilities/security/) [Field note Controls that depend on discipline fail during busy weeks Read](https://idataraya.com/insights/controls-that-need-discipline/) [Field note Degrading well beats recovering fast Read](https://idataraya.com/insights/degrading-well/) [Field note Taking over a system you did not build: the first ninety days Read](https://idataraya.com/insights/inheriting-a-system/) [Field note What breaks in a bank integration, and roughly when Read](https://idataraya.com/insights/what-breaks-in-bank-integrations/) [Field note We build, and we maintain: inside the idataraya engagement model Read](https://idataraya.com/insights/the-engagement-model/) [Field note The asasii suite: production engines we compose every system from Read](https://idataraya.com/insights/the-asasii-suite/) [Field note Settlement files never agree on the first pass Read](https://idataraya.com/insights/settlement-files/) [Field note The timeout with an unknown outcome Read](https://idataraya.com/insights/timeout-unknown-outcome/) --- --- title: "Degrading well beats recovering fast | idataraya" description: "An operation usually needs to keep trading in a reduced way more than it needs a component back in five minutes. Deciding what that reduced way is beforehand is the whole trick." url: "https://idataraya.com/insights/degrading-well/" --- Resilience # Degrading well beats recovering fast By Shamsul Bahrin, Neo Jun Hao and Revathi Arumugam for idataraya Field note 15 October 2026 6 minute read ![A shop staying open during a power outage](https://idataraya.com/landing-v2/insights/degrading-well.jpg) ## Key Takeaways Resilience work concentrates on shortening outages. The business usually cares more about what it can still do during one. - A recovery target answers how long until normal. A degradation plan answers what happens in the meantime, which is the question the counter is actually asking. - Degraded modes have to be designed, built, and practised, or staff will invent one under pressure and it will not reconcile afterwards. - The decision is per function, not per system: some things must keep working, some can queue, and some should stop cleanly. An operation usually needs to keep trading in a reduced way more than it needs a component back in five minutes. Deciding what that reduced way is beforehand is the whole trick. Continuity planning tends to produce two numbers: how long a system may be unavailable, and how much data may be lost. Both are useful and neither describes what an operation does during the outage. For most businesses the more pressing question is not when the system comes back. It is whether the shop can still sell something, whether the ward can still admit a patient, whether the driver can still complete the run. ## Every business already has a degraded mode The important observation is that the degraded mode exists whether or not anyone designed it. When a system goes down, staff do not stop. They improvise: a notebook, a calculator, a stack of manual receipts, a photograph of a screen, an arrangement with a regular customer. That improvised mode has two characteristics. It keeps the business trading, which is why it happens. And it produces records that will not reconcile, because they were never designed to be entered into anything afterwards. So the choice is not between a degraded mode and no degraded mode. It is between one that was designed and one that is invented during the incident. ## Decide function by function The useful analysis is not per system, it is per function, and it sorts into three categories. Functions that must continue, because stopping them stops the business or harms someone: taking payment, admitting a patient, dispatching a vehicle. These need a genuine offline or reduced path, built and tested. Functions that can queue: reporting, reconciliation, non urgent approvals, anything whose delay costs nothing as long as it is not lost. These need a durable queue and a clear catch up, not an alternative path. Functions that should stop cleanly: a promotion that cannot be validated, a credit decision that cannot be checked, a discount that requires an approval nobody can give. Stopping these deliberately is safer than allowing them to proceed unverified, and telling staff so in advance prevents the improvisation. ## The record is the hard part Most degraded modes fail not during the outage but afterwards, at the point where the manual records have to become system records. A counter that took forty sales on paper produces forty entries someone must key in, with prices that may have been wrong, stock that was not drawn down, and payments that were accepted in a form the system cannot now match. The outage lasted two hours. The reconciliation lasts a week. A designed degraded mode records locally, in the same shape the system uses, and reconciles automatically when service returns. That is the difference between an application that works offline and a paper fallback, and it is usually the whole justification for building the former. ## Practise the mode, not the recovery Organisations rehearse failover, which tests the technology, and rarely rehearse trading in a degraded state, which tests everything else. The valuable drill is the one where the counter is told the system is unavailable for an hour and has to serve real customers through the designed path, with the reconciliation performed afterwards. It surfaces the parts nobody thought about: who authorises what, where the printed price list is, whether anyone knows the offline procedure, whether the reconciliation actually works with real data. It also produces the only assurance that matters, which is that the plan has been executed by the people who will have to execute it, rather than written by people who will not. Share Subscribe Get new field notes when we publish them [Enter email](https://idataraya.com/contact/) ## Related content [Capability Business Resilience Read](https://idataraya.com/capabilities/business-resilience/) [Field note Taking over a system you did not build: the first ninety days Read](https://idataraya.com/insights/inheriting-a-system/) [Field note What breaks in a bank integration, and roughly when Read](https://idataraya.com/insights/what-breaks-in-bank-integrations/) [Field note We build, and we maintain: inside the idataraya engagement model Read](https://idataraya.com/insights/the-engagement-model/) [Field note The asasii suite: production engines we compose every system from Read](https://idataraya.com/insights/the-asasii-suite/) [Field note Settlement files never agree on the first pass Read](https://idataraya.com/insights/settlement-files/) [Field note The timeout with an unknown outcome Read](https://idataraya.com/insights/timeout-unknown-outcome/) [Field note The workarounds are the requirements Read](https://idataraya.com/insights/workarounds-are-requirements/) [Field note An untested restore is a belief, not a backup Read](https://idataraya.com/insights/untested-restore/) --- --- title: "Taking over a system you did not build: the first ninety days | idataraya" description: "Inheriting an operational system is mostly archaeology: what it depends on, what fails routinely, and which parts nobody has dared touch. What you do in the first ninety days decides the next three years." url: "https://idataraya.com/insights/inheriting-a-system/" --- Operations # Taking over a system you did not build: the first ninety days By Wan Rosli Hashim, Yong Kar Mun, Manoj Sivalingam and Siti Aminah Jalil for idataraya Field note 29 October 2026 8 minute read ![An older industrial control panel](https://idataraya.com/landing-v2/insights/inheriting-a-system.jpg) Inheriting an operational system is mostly archaeology: what it depends on, what fails routinely, and which parts nobody has dared touch. What you do in the first ninety days decides the next three years. Taking over a running system is a different discipline from building one. The thing already works, people already depend on it, and nobody is going to stop using it while you learn. It is also the more common situation. Most systems in production outlive the team that wrote them, and the handover is frequently partial: some documentation, a few weeks of overlap if you are fortunate, and a set of assumptions that were never written down because they were obvious to whoever held them. ## Weeks one to three: find out what it touches The first useful artefact is not a code review. It is a map of what the system connects to and what connects to it. Every inbound and outbound interface. Every scheduled job and what it produces. Every report someone receives. Every file dropped somewhere for another team. Every credential and certificate, with its expiry. Every external service it calls and who owns the contract. That last category is where the unpleasant surprises live: a payment interface renewing in six weeks, a certificate expiring in two months, an API version being retired, a licence tied to a person who has left. Each of those is a scheduled outage waiting to happen and none of them will appear in the code. > The instinct to rewrite is strongest in the first month, when you understand the system least and are most confident about it. ## Weeks two to six: learn what fails routinely Every long running system has a set of failures that happen regularly and are handled by somebody who knows what to do. Those failures are not in the ticket system, because they are not treated as incidents. They are treated as Tuesday. Find them by asking the people who operate the system, in their own words: what do you check every morning, what goes wrong most often, what do you do when it does, and what is the thing you hope does not happen while you are on leave. The answers are the operational reality, and they are usually more valuable than any document. They also identify the single points of knowledge, which are the biggest risk you have just inherited and the one nobody puts on a register. ## Resist the rewrite The instinct to rewrite is strongest in the first month, when you understand the system least and are most confident about it. Code that looks unnecessarily complicated is sometimes unnecessarily complicated. More often it encodes a requirement that is real and undocumented: a customer with an unusual arrangement, a regulatory case, a workaround for a defect in something downstream, a behaviour agreed in a meeting in 2019. The rule that has served well: do not remove anything you cannot explain the purpose of. If you cannot find the reason, that is information about your understanding, not evidence that there is no reason. Write down what you suspect it does, come back in two months, and decide then. ## Weeks four to nine: make it observable before changing it Inherited systems are usually observable only through their failures: someone notices a wrong number, or a customer complains. Before making changes, establish what normal looks like. Volumes by hour and by day. Processing times. Error rates by type. The size and timing of each interface. Not because these are interesting in themselves, but because the first change you make needs a baseline to be judged against, and you will not be able to construct one retrospectively. This is also the phase that most reliably finds the things nobody knew were happening: the job that has been failing silently for a year, the interface that has not received a file since March, the retry loop that runs eleven thousand times a night. ## Weeks six to twelve: make one change that matters At some point in the first ninety days the team needs to make a real change and put it into production, and it should be chosen deliberately. The right first change is small, visible to the operators, and fixes something they complain about. It proves the whole path works: development, testing, deployment, rollback, and the relationship with the people who use the system. It also buys credibility, which will be needed later when something goes wrong. The wrong first change is a large refactor with no visible benefit, which risks everything and demonstrates nothing to anyone outside the team. ## What ninety days should leave behind At the end of the first ninety days the useful outcome is not a roadmap. It is a set of things that did not exist before. A map of dependencies with owners and expiry dates. A written account of the routine failures and what to do about each. A baseline of what normal looks like. A list of the things nobody dares touch, with what is known about why. At least one change delivered through the whole path. And, critically, more than one person who knows each of those things. Everything after that is ordinary engineering. The first ninety days are about converting somebody else's undocumented system into your team's known one, and that conversion is the work. Share Subscribe Get new field notes when we publish them [Enter email](https://idataraya.com/contact/) ## Related content [Capability Operations Read](https://idataraya.com/capabilities/operations/) [Field note An untested restore is a belief, not a backup Read](https://idataraya.com/insights/untested-restore/) [Field note One catalogue, or the argument you have every month Read](https://idataraya.com/insights/one-catalogue/) [Field note Your terminal estate is a logistics business. Run it like one. Read](https://idataraya.com/insights/provisioning-a-terminal-fleet/) [Field note Seasonal hiring is a software requirement Read](https://idataraya.com/insights/seasonal-hiring-software/) [Field note Arrears are a process, and the process needs a trail Read](https://idataraya.com/insights/arrears-need-a-trail/) [Field note The third-year cloud bill Read](https://idataraya.com/insights/third-year-cloud-bill/) [Field note What breaks in a bank integration, and roughly when Read](https://idataraya.com/insights/what-breaks-in-bank-integrations/) [Field note We build, and we maintain: inside the idataraya engagement model Read](https://idataraya.com/insights/the-engagement-model/) --- --- title: "What breaks in a bank integration, and roughly when | idataraya" description: "The failures are predictable enough to plan around. They arrive in a consistent order, and almost none of them are in the part of the work that gets estimated." url: "https://idataraya.com/insights/what-breaks-in-bank-integrations/" --- Integration # What breaks in a bank integration, and roughly when By Hairul Azman, Ching Wai Loon and Sridhar Balan for idataraya Field note 12 November 2026 7 minute read ![A glass office tower seen from street level](https://idataraya.com/landing-v2/insights/what-breaks-in-bank-integrations.jpg) ## Key Takeaways Bank integrations fail in a recognisable sequence, and each stage has a countermeasure that costs almost nothing if applied early. - Access comes first and takes longest: environments, credentials, network paths, and approvals from teams with their own queues. - The specification will be accurate and incomplete, and the gaps are found by sending real traffic rather than by reading it more carefully. - The genuinely hard part arrives last: reconciliation, exception handling, and proving both sides agree after a disagreement. The failures are predictable enough to plan around. They arrive in a consistent order, and almost none of them are in the part of the work that gets estimated. Integrating with a bank is not technically difficult. The protocols are ordinary, the message formats are documented, and the actual code is usually a modest amount of work. It is nonetheless the part of most programmes that slips, and it slips in a consistent pattern. Knowing the pattern does not make it faster, but it does make the plan honest. ## Stage one: getting in at all The first phase is not development, it is access, and it is routinely omitted from estimates because it does not look like work. A test environment has to be requested and provisioned. Credentials and certificates have to be issued, by a team that issues them in batches. Network connectivity has to be established, which may mean a dedicated link or a firewall change requiring approval on both sides. Somebody has to be nominated as the contact, and the security review has to complete before anything is switched on. None of this is under the programme's control. All of it is sequential. It is common for this stage alone to consume more elapsed time than the development it precedes, and it starts the moment someone asks rather than the moment the team is ready. ## Stage two: the specification is right and incomplete The documentation will be accurate about the fields and the formats. It will be quiet about the parts that matter operationally. Which optional fields are in practice mandatory for your transaction type. What the response actually looks like for the error cases, as opposed to the success case shown in the examples. How reference fields are truncated, and where. What the real timeout behaviour is under load rather than the documented one. Whether the test environment behaves the same as production, which it frequently does not. There is no amount of careful reading that surfaces these. They are found by sending real traffic early, including deliberately malformed and edge case traffic, and comparing what comes back to what was expected. ## Stage three: the environment is shared The bank's test environment serves every integration the bank is running, which is more than you can see. It is refreshed on a schedule that is not yours, sometimes resetting the data you built your test cases around. It is taken down for maintenance with notice you may not receive. Its behaviour changes when another party's work is deployed. It has data that is stale, or scrubbed in ways that break assumptions, or belongs to a different test bank entirely. The countermeasure is to make your own testing independent of that environment's state wherever possible: create what you need at the start of a run rather than depending on data being there, and keep a recorded set of real responses so you can continue working when the environment is unavailable. ## Stage four: the part that was never estimated The last stage is the one that actually determines whether the integration is production ready, and it is rarely in the original scope. What happens when a request times out and the outcome is unknown. How a duplicate is prevented and detected. How both sides prove at the end of a day that they hold the same set of transactions, and what happens when they do not. Who is notified when a file does not arrive, and after how long. How a reversal is handled if it arrives after the day has been closed. What the operational procedure is when the bank's service is down and yours is not. Every one of these requires a decision from both parties, not just from your team, which means each is subject to the same queue that made stage one slow. Starting them at the end of the programme is the single most common reason a go live date moves. ## Plan it backwards The correction is straightforward and rarely applied: begin with stage four. Agree the reconciliation approach, the exception handling, and the operational procedures at the point the integration is scoped, while there is time for the counterparty's queue. Request access on the same day, before any development starts. Send one real transaction end to end as the first deliverable rather than as the last. The development effort was never the risk. The dependencies were, and they are the only part of the plan that cannot be compressed by working harder. Share Subscribe Get new field notes when we publish them [Enter email](https://idataraya.com/contact/) ## Related content [Field note We build, and we maintain: inside the idataraya engagement model Read](https://idataraya.com/insights/the-engagement-model/) [Field note The asasii suite: production engines we compose every system from Read](https://idataraya.com/insights/the-asasii-suite/) [Field note Settlement files never agree on the first pass Read](https://idataraya.com/insights/settlement-files/) [Field note The timeout with an unknown outcome Read](https://idataraya.com/insights/timeout-unknown-outcome/) [Field note The workarounds are the requirements Read](https://idataraya.com/insights/workarounds-are-requirements/) [Field note An untested restore is a belief, not a backup Read](https://idataraya.com/insights/untested-restore/) [Field note Anything that assumes a signal at the door will produce paper at the depot Read](https://idataraya.com/insights/signal-at-the-door/) [Field note One catalogue, or the argument you have every month Read](https://idataraya.com/insights/one-catalogue/) [Field note The online store that sells what the counter already sold Read](https://idataraya.com/insights/online-store-oversell/) --- --- title: "We build, and we maintain: inside the idataraya engagement model | idataraya" description: "Most systems are handed at go-live to a support desk that never saw them built. We do not work that way, and it changes what gets designed as much as what gets fixed." url: "https://idataraya.com/insights/the-engagement-model/" --- Perspective # We build, and we maintain: inside the idataraya engagement model By Izzat Rahman, Loh Pei Qi and Thevan Murugan for idataraya Field note 26 November 2026 6 minute read ![An engineering team working at a whiteboard](https://idataraya.com/landing-v2/insights/the-engagement-model.jpg) Most systems are handed at go-live to a support desk that never saw them built. We do not work that way, and it changes what gets designed as much as what gets fixed. The conventional arrangement in systems delivery separates two things: a project team builds, and at go live a support function takes over. The people who made every design decision leave, and the people who will live with those decisions arrive without having seen any of them made. It is an efficient way to organise a delivery business. It is a poor way to operate a system, and the reasons are structural rather than a matter of anyone's competence. ## What the handover actually loses Documentation transfers facts. It does not transfer the reasoning that produced them. Why a particular retry interval was chosen, and what happens if it changes. Which parts of the code are load bearing and which are incidental. Which behaviour is deliberate and which is an accident that nobody has needed to correct. What was considered and rejected, and why the obvious approach was not taken. That knowledge does not fit in a handover document, because most of it was never articulated. It exists as judgement in the people who made the decisions, and a handover is the moment it stops being available. > A team that will be answering the phone about a system at two in the morning designs it differently from a team that will not. ## The incentive problem There is a second effect, and it is the more consequential one. A team that hands a system over at go live is measured on delivering to a date. A team that will operate what it built is measured on that plus everything that happens afterwards. Those produce different decisions, consistently and predictably. The first team accepts a manual step because there is no time to automate it, and the manual step becomes somebody else's Tuesday morning forever. The second team automates it, because the somebody is them. The first defers observability because it does not demonstrate to a sponsor. The second builds it, because without it the first incident is diagnosed blind. A team that will be answering the phone about a system at two in the morning designs it differently from a team that will not. That is not a matter of professionalism. It is what happens when the consequence returns to the decision. ## How we work The engineers who architect and build a system are the engineers who run it. There is no handover to a separate support organisation, because there is no separate support organisation to hand it to. In practice that means a fault is diagnosed by someone who already knows why the code behaves the way it does, rather than by someone reading it for the first time under pressure. A change requested after go live is assessed by people who know what it will disturb. And the system continues to be improved rather than merely kept alive, because the same team that would have to fix a recurring problem is able to remove its cause. It also means we are careful about what we take on, since every engagement is a long one from our side. That is a real constraint on the business and we accept it, because the alternative is a delivery model whose incentives we do not believe in. ## What this asks of a client This model is not free of obligations on the other side, and it is worth being direct about them. It works best where the relationship is expected to last, because the value compounds over years rather than appearing at go live. It requires access to the operational reality rather than only to a specification, since the design decisions that matter depend on how the work is actually done. And it asks for a decision maker who remains involved after launch, because the improvements that matter most are identified in the first year of running, not in the requirements phase. In exchange, the system does not degrade into something nobody understands. That is the whole proposition, and it is a longer term one than most procurement is set up to evaluate. Share Subscribe Get new field notes when we publish them [Enter email](https://idataraya.com/contact/) ## Related content [Field note The asasii suite: production engines we compose every system from Read](https://idataraya.com/insights/the-asasii-suite/) [Field note Settlement files never agree on the first pass Read](https://idataraya.com/insights/settlement-files/) [Field note The timeout with an unknown outcome Read](https://idataraya.com/insights/timeout-unknown-outcome/) [Field note The workarounds are the requirements Read](https://idataraya.com/insights/workarounds-are-requirements/) [Field note An untested restore is a belief, not a backup Read](https://idataraya.com/insights/untested-restore/) [Field note Anything that assumes a signal at the door will produce paper at the depot Read](https://idataraya.com/insights/signal-at-the-door/) [Field note One catalogue, or the argument you have every month Read](https://idataraya.com/insights/one-catalogue/) [Field note The online store that sells what the counter already sold Read](https://idataraya.com/insights/online-store-oversell/) [Field note What tender documents get wrong about maintenance Read](https://idataraya.com/insights/tendering-for-maintenance/) --- --- title: "The asasii suite: production engines we compose every system from | idataraya" description: "asasii is not one product. It is a set of engines that have been through production in more than one sector, assembled per client rather than configured from a single template." url: "https://idataraya.com/insights/the-asasii-suite/" --- Platform # The asasii suite: production engines we compose every system from By Nurhaliza Jamil, Cheah Kok Wai and Ilangovan Raju for idataraya Field note 10 December 2026 7 minute read ![A close view of a circuit board](https://idataraya.com/landing-v2/insights/the-asasii-suite.jpg) ## Key Takeaways The suite exists because the same problems recur across sectors under different names, and rebuilding them each time is neither faster nor better. - A retail counter, a hospital cashier and a campus canteen are the same acceptance problem with different rules on top, so the engine is shared and the rules are not. - Modules read one another's records rather than holding copies, which is what removes the reconciliation work that fragmented systems generate. - Composition beats configuration: a client gets the modules their operation needs, not a single product with the irrelevant parts switched off. asasii is not one product. It is a set of engines that have been through production in more than one sector, assembled per client rather than configured from a single template. Every sector describes its problems in its own vocabulary. A hospital has episodes and claims, a strata community has parcels and charges, a developer has units and progressive billing, a logistics operator has consignments and proof of delivery. Underneath a good deal of that, the same engines keep appearing. Something has to take a payment reliably at a counter that may be offline. Something has to hold a register of who owes what and prove what was demanded. Something has to reconcile what was taken against what settled. Something has to give the other party a portal to see their own position. asasii is the set of those engines, kept in production rather than rewritten per project. ## What is actually shared The acceptance engine is the clearest case. asasii POS at a retail counter, the counter and kiosk at a hospital registration desk, campus payment at a canteen, and outlet point of sale in a restaurant are the same problem: capture a sale, drive a payment terminal directly so the amount is keyed once, work when the network does not, and reconcile on reconnection. The rules on top differ completely. A hospital needs the charge posted to an episode and possibly a guarantee letter. A campus needs a stored value account a parent topped up. A hotel outlet needs the charge posted to a folio. Those are genuinely different and they sit above an engine that is genuinely the same. The same holds for the register and arrears engines, which appear as strata charges, tenant billing, student fees, and agency collections. The ageing, the reminder sequence, the arrangement tracking, and the evidence of what was served are identical work. What is being charged for is not. > A platform is only worth having if it removes work. Ours earns its place by removing the joins, not by covering the most ground. ## Modules read, they do not copy The property that makes the suite worth having is not the module count. It is that modules read one another's records rather than holding their own copies. The online store and the counter read one catalogue and one stock position, which is the entire reason a store built this way cannot oversell what the counter has already sold. The bursar reads the same fee ledger the parent portal and billing write to. The car park and access modules read the register rather than maintaining a second list of who lives or works in a building. Fleet management holds the terminal estate that acceptance runs on, so a device's configuration and its transactions are the same record. Fragmented systems generate reconciliation as a by product of being separate. Removing the copies is what removes that work, and it is not something a client can retrofit by buying more integration. ## Composed, not configured A single product covering many sectors ends up as a large configuration exercise, where most of what is delivered is switched off and the parts that matter are bent into a shape they were not designed for. The suite is assembled instead. A strata community runs the register, arrears, the resident portal, facilities, access, and utilities. A logistics operator runs dispatch, the hub, the driver application, consignments, and settlement. A developer runs sales, purchasers, progressive billing, contracts, defects, and then building management once the units are handed over. There is no common product with irrelevant sections disabled, because there is no common product. What is common is the spine underneath: one identity for a customer or a parcel or a student, one ledger, one catalogue where a catalogue applies, and one set of records that every module reads. ## Where the suite stops It is worth being clear about the limits, because a platform that claims to cover everything is either lying or bloated. asasii does not replace a general ledger, a clinical system, a core banking platform, or a building's mechanical controls. Those are specialist domains with their own vendors and their own regulatory footing, and the correct posture towards them is a well designed interface rather than an attempt at replacement. What the suite covers is the operational layer between them: where money is taken, what is owed, what was delivered, and who can see it. That layer is where the recurring work sits in every sector we work in, and it is the layer most often assembled from three vendors who never met. A platform is only worth having if it removes work. Ours earns its place by removing the joins, not by covering the most ground. Share Subscribe Get new field notes when we publish them [Enter email](https://idataraya.com/contact/) ## Related content [Field note Settlement files never agree on the first pass Read](https://idataraya.com/insights/settlement-files/) [Field note The timeout with an unknown outcome Read](https://idataraya.com/insights/timeout-unknown-outcome/) [Field note The workarounds are the requirements Read](https://idataraya.com/insights/workarounds-are-requirements/) [Field note An untested restore is a belief, not a backup Read](https://idataraya.com/insights/untested-restore/) [Field note Anything that assumes a signal at the door will produce paper at the depot Read](https://idataraya.com/insights/signal-at-the-door/) [Field note One catalogue, or the argument you have every month Read](https://idataraya.com/insights/one-catalogue/) [Field note The online store that sells what the counter already sold Read](https://idataraya.com/insights/online-store-oversell/) [Field note What tender documents get wrong about maintenance Read](https://idataraya.com/insights/tendering-for-maintenance/) [Field note Audit evidence is a feature, not a report you run later Read](https://idataraya.com/insights/audit-evidence/)