Frequently asked questions

We estimate from the scope, not from a rate card. After a first conversation we break the work into parts, size each one and write down the assumptions behind the estimate. The main drivers are the number of systems and integrations, the state of your data, security and regulatory requirements, the testing needed and the seniority of the team. You receive a written estimate with options, so you can choose what to do first. You see the price and the timeline before we start.

The main drivers are the state of your data, the number of systems to integrate, how accurate the system must be, and how much human review the process needs. Running costs matter too: model usage, hosting and monitoring. We estimate after a short discovery, separate build cost from running cost, and show how running cost changes with volume so there are no surprises later.

Build cost depends on the number and state of your sources, the integrations and permissions involved, and how strict the accuracy bar is. Running cost depends on usage, the model chosen, how much text is sent with each request and caching. We estimate both, and we show how a smaller model or better retrieval can bring the running cost down.

The main drivers are the state and accessibility of your data, whether labels exist or must be created, how many systems the model must connect to, and the level of explanation and documentation your regulators expect. Running costs depend on prediction volume and whether results are needed in real time or in batches. We estimate once the data review is done.

Build cost depends on the number and complexity of sources, how clean they are, and how many subject areas and reports are in scope. Running cost depends on data volumes, refresh frequency and query patterns. We estimate both, design to control compute spend, and set up cost monitoring so usage does not grow unnoticed.

The number of document types and layouts, the quality of the scans, how many validation rules and systems are involved, and the volume processed. Running cost depends on volumes and the extraction services used. We estimate after testing a sample of your documents, and we show the expected share of documents that will still need a person.

Scope is the main driver: how many user roles, workflows and screens, how many systems the software must connect to, and how strict the security, audit and availability needs are. The state of your data and the number of people who must approve decisions matter too. We estimate after discovery, from a prioritised backlog, so you can choose what goes into the first release and what waits.

The number of user roles and workflows, the integrations behind the application, the languages and layouts it must support, and its security and audit needs. Design depth matters too: a tool for a small internal team needs less than a public portal your clients rely on. We estimate from the backlog after discovery, so you can decide what goes into the first release.

The number of journeys and screens, whether you need a native app for each platform or one cross-platform app, the back-end work, and the security the app needs. Offline use, payments, device features and the range of devices to support add effort. Store releases and keeping up with new operating system versions are ongoing costs to plan for.

The number of applications and environments, how far they are from automated deployment today, the compliance controls you must meet, and whether workloads move between providers or out of your own data centre. Ongoing operation is a separate decision: we can run the platform with you, or hand it over once your team is ready.

Often, but we will not promise a figure before we have looked. Common savings come from resources nobody uses, oversized instances, storage that never expires and environments that run when nobody is working. We tag spending by team and service first, so savings are measured rather than guessed, and we rank what we find by effort and risk.

The number of applications and journeys in scope, how testable the current code is, the state of your test data and environments, and how many integrations need simulating. An older application without stable test hooks takes more effort than a new one built with testing in mind. We start with the highest-risk journeys, so the value arrives early.

The number of user groups and journeys, how much research is needed, whether a design system already exists, and how many platforms and languages the design must cover. Redesigning an established product with many screens takes more than designing a focused new tool. We scope design in stages, so you can review the findings and flows before committing to the full interface.

The size and complexity of the old system, the quality of its data, the number of systems that depend on it, and how much must change rather than be kept. Old languages and databases that few engineers know add effort. Because the work is incremental, you can fund it in stages and see each stage’s result before approving the next.

The number of interfaces, the complexity of the mapping and business rules, the volumes and timing each flow needs, and whether middleware licences are involved. Data clean-up and testing with partners add effort. We estimate per interface after the assessment, so you can see the cost of each flow and decide the order.

The number of banks and channels, the payment types and countries in scope, how much your ERP already supports, and how complex your matching rules are. Signing and encryption requirements and each bank’s test process add effort. We estimate per bank and per flow after discovery, so you can phase the work and its cost.

The number of providers, terminal types and sales channels, whether the acquirer uses ISO 8583 or an API, the certification steps each provider requires, and the number of stores to roll out. Settlement and reconciliation rules add effort when fees and payouts are complex. We estimate per provider and per flow after the mapping step.

The number of partners and flows, the quality of their APIs, the mapping and business rules, volume and timing needs, and any integration-platform licences. Identity work and certification with a partner add effort. We estimate per connection after the inventory, so you can choose the order and see the cost of each.

A dedicated team is usually charged as a monthly cost for the agreed roles, so you can plan your budget. The cost depends on the number of people, their seniority and skills, and any cover outside normal hours. If you prefer to pay for actual time, we can work on time and materials. You see the price and the timeline before we start.

Usually on time and materials: a rate per engineer for the time they work, or a monthly rate for a full-time placement. The rate depends on the skills and seniority of the role and on any work outside normal hours. You see the price and the timeline before we start.

It can. Cost depends on the roles, seniority and skills the work needs, and on who can provide them. You see the price and the timeline before we start. Any change to the mix is agreed with you first.

A well-defined scope can be priced as a fixed price for that scope, with changes handled through change control. Where the scope is less certain, we price discovery separately and then the build, or work on time and materials with a budget we report against. You see the price and the timeline before we start.

Usually as a fixed scope with a fixed fee, agreed after a short scoping conversation, or as a number of consultant days for open-ended advisory work. The price depends on the size of the estate to review, the number of options to compare and the depth of analysis the decision needs. You see the price and the timeline before we start.

It is usually a fixed fee for a fixed scope, agreed after a short scoping call. The price depends on the number of business areas involved, how many use cases are assessed in depth and how much hands-on review of your data and systems is needed. You see the price and the timeline before we start.

The number of systems and partners involved, the regulatory controls that apply, the volume and speed the system must handle, and how much testing partners require before go-live. Partner onboarding, such as a bank or processor certification, often sets the pace more than the code. We estimate after discovery and break the work into stages you can fund and approve one at a time.

The number of systems, stores and channels, how well the POS and the ERP expose their data, and how many exceptions need rules, such as returns across channels or split payments. Rolling out store by store adds testing effort too. We estimate after reviewing the systems and a sample of real transactions.

The number of partners and formats, how many message types each one needs, the quality of the partners’ test environments, and how much of the process still runs on paper or email. We estimate per partner and per flow after a review, so you can start with the partners that matter most and add the rest in stages.

The number of systems to integrate, the vendor approvals needed, the privacy and clinical safety work, and the accessibility and usability testing with patients and staff. We estimate after discovery and break the work into stages, starting with the one that removes the most manual work.

The number of services and integrations, the identity and payment providers involved, the accessibility and security assessments, and the user research the service needs. We price per stage, so a discovery or a pilot can be approved on its own before the full build.

The number of systems and partners, how many message types each one needs, the quality of the data, the extension options of your ERP version, and how much testing your partners require. We estimate per flow after discovery, so you can start with the flows that save the most effort.

The commitment depends on the model and is agreed with you. A project runs to its agreed scope. Teams and placements have notice periods, so that people can join and leave properly and work is handed over. We set these terms out in writing before anything starts.

Intellectual property in the work we build for you is yours from the first commit — no assignment step at the end. That covers the custom code, documentation and other deliverables made for you. Anything we bring that existed before, such as internal tools or libraries, stays ours, and you receive a licence to use it in your systems. Open-source components keep their own licences, and we list them for you.

Yes. We will sign a mutual non-disclosure agreement before you share anything confidential, on your template or ours. Everyone who works on your project is bound by confidentiality obligations, whether they are XSIS employees or members of an outsourced team.

Intellectual property in the work we build for you is yours from the first commit — no assignment step at the end. That includes the code, prompts, evaluation sets and fine-tuned models produced for you, and your data stays yours. Any XSIS tools that existed before stay ours and are licensed to you. Third-party models and services remain under their own licences, which we list for you so you know what each component allows.

Intellectual property in the work we build for you is yours from the first commit — no assignment step at the end. That includes the code, prompts, evaluation sets, retrieval indexes and any fine-tuned model weights produced for you. Any XSIS tools that existed before stay ours and are licensed to you. Commercial models remain the vendor’s and are used under their terms, which we list for you. Your documents and data remain yours throughout.

Intellectual property in the work we build for you is yours from the first commit — no assignment step at the end. That includes the trained models, feature code, pipelines and documentation produced for you, and your data stays yours. Any XSIS tools that existed before stay ours and are licensed to you. Open-source libraries we use remain under their own licences, which we record for you.

Intellectual property in the work we build for you is yours from the first commit — no assignment step at the end. The custom code, designs and documents the team produces live in your own repositories and tools. Any XSIS tools that existed before stay ours and are licensed to you. Everyone on the team, including engineers from outsourced teams, is bound by the same confidentiality terms.

Intellectual property in the work we build for you is yours from the first commit — no assignment step at the end. The work an engineer produces for you lives in your own repositories. Any XSIS tools that existed before stay ours and are licensed to you. Each engineer signs our confidentiality terms and follows your security policies while they work in your systems.

Intellectual property in the work we build for you is yours from the first commit — no assignment step at the end. That covers the custom software, designs and documents delivered for you. Any existing tools or libraries of ours used in the project stay ours, are named in the contract and are licensed to you.

Intellectual property in the work we build for you is yours from the first commit — no assignment step at the end. Connectors are delivered with their source code, tests and documentation, so your team or another supplier can maintain them. Any XSIS tools that existed before stay ours and are licensed to you. Partner APIs and integration-platform licences remain under those vendors’ own terms.

XSIS employs its own engineers, who lead projects, set the technical direction and are accountable for quality. Where a project needs more capacity or a specialist skill, we add engineers from vetted outsourcing partners. They work to the same standards, contracts and security rules, and you always know who is on your team and who employs them.

You interview every engineer before they join; no blind placements. If someone is not the right fit, we replace them at no cost. Tell your delivery lead, and we plan a handover so knowledge stays with the team. The same applies if someone has to leave the project for their own reasons.

Yes. Many clients want their engineers in the same repository from the start, so knowledge stays in-house. We agree the working rules together: code review, branching, the definition of done and who approves releases. Your engineers can join the iterations, pair with ours, or take over parts of the system when they are ready.

That is the aim. Everything is defined as code and documented, and your engineers review and approve changes with us from the start. We pair with them on incidents and releases, write runbooks for the common tasks, and step back as they take over. If you prefer us to keep running the platform, that can continue under a support agreement.

Yes. We often join an in-house QA team to add automation skills, take on performance or security testing, or cover a busy period. We agree how the work is split, use the same tools and backlog, and train your testers to extend the suites we build.

In the same team and at the same rhythm. Designers join planning, hand over designs and components with their states and behaviour documented, and review what is built before it ships. Engineers join research and design reviews early, so ideas that are hard to build are caught before they are polished.

Yes, and that is common. We recover the knowledge from the code, the data, the logs and the people who use the system, and we capture what it actually does in characterisation tests. Those tests become the specification the new parts must meet, so undocumented behaviour is kept unless you decide to change it.

We start from the skills the work needs, not from who is free. Candidates go through technical interviews and practical exercises run by our senior engineers, and we check their experience against the kind of work you do. Then we send you their profiles, and you interview them yourself. Nobody joins your team without your approval.

You decide what the team works on: your product owner sets the priorities and accepts the work. We run the team day to day through a team lead who plans the work, removes blockers, looks after quality and reports to you. Line management, performance and replacement of people stay with XSIS.

You interview every engineer before they join; no blind placements. If someone is not the right fit, we replace them at no cost. Tell your team lead or your account contact as soon as you see it. We also look at the role and the briefing, which are sometimes the real cause, and we plan an overlap so that knowledge is handed over and not lost.

Yes. The team follows your roadmap. You can add roles when a new stream of work starts and release them when it ends. We agree each change with you in advance, with enough notice to bring people in properly or hand their work over cleanly. The notice terms are set out in the contract.

With staff augmentation, our engineers join your team and your managers direct their work day to day. With a dedicated team, we provide a whole team with its own lead, and we run it day to day while you set the priorities. Staff augmentation fits when you already have the management and the process. A dedicated team fits when you want us to carry more of that.

Our senior engineers run technical interviews and practical exercises for each candidate against your role brief. We check their past work and the kind of systems they have built. Engineers from outsourced teams go through the same assessment as our own. You then interview them yourself, and only the people you choose join.

Your managers direct the work: what to build, in what order, and how it is reviewed. XSIS stays the employer or the contracting party. We handle pay, leave, equipment, performance support and replacement, and our account contact keeps in touch with you and with the engineer.

You interview every engineer before they join; no blind placements. If someone is not the right fit, we replace them at no cost. Tell us as early as you can, and we plan the handover so that work in progress is not lost.

Yes. You can add people when a new piece of work starts and release them when it is done. The contract sets the notice needed on both sides, so that new engineers can be found and assessed properly and departing ones can hand their work over.

It means our own engineers lead every engagement and carry the responsibility for it, and we add engineers from vetted outsourced teams when the work needs more people or a skill we do not hold in-house. The outsourced engineers work under our contract and our standards, inside a team that our people lead.

Yes. The team map lists every person, their role and who employs them. You interview every engineer before they join; no blind placements. We do not add or swap people without telling you first.

XSIS is. Your contract is with us, and our delivery lead answers for the work of the whole team, whoever employs each engineer. That is why our engineers review outsourced engineers’ changes before they are merged, and why one set of standards applies to everyone.

Yes. Tell us before we propose the team. Some clients need certain work, such as access to production data, to be done only by XSIS engineers. We plan the roles around that and tell you plainly if it changes what we can deliver or when.

It depends on the model, and we say so in writing. In project-based delivery, XSIS is accountable for delivering the agreed scope. In a dedicated team, XSIS is accountable for running the team well and you are accountable for its priorities. In staff augmentation, your managers direct the work and XSIS is accountable for the people it provides.

Yes. A dedicated team can run your product while a separate project delivers a bank integration, or we can place a specialist in your own team beside a team we run. Each part has its own terms, and one XSIS contact coordinates them.

We agree an evaluation set with your team before building: real examples with the answers your experts expect. Every version of the system is scored against it, and reviewers check a sample of the harder cases. You decide the threshold for release. In production, we keep measuring and route uncertain cases to a person rather than guessing.

We work with commercial models such as OpenAI GPT models, Anthropic Claude and Google Gemini, with open models such as Meta Llama and Mistral, and with classic machine learning where it fits better. We choose per task on quality, cost, latency and where the model may run. We design so the model can be changed later. Naming a vendor does not mean a partnership.

We reduce the risk in layers. The model answers from retrieved passages of your content and must cite them. Guardrails check that claims are supported by those passages. When the sources do not contain an answer, the feature says so instead of guessing. The evaluation set measures how often answers are unsupported, and we do not release until that rate meets the threshold you agree.

For answering from your documents, retrieval is usually the better start: it keeps answers current, shows sources and respects permissions. Fine-tuning helps when you need a consistent format or style, a specialised vocabulary, or a smaller model that runs cheaply. Many systems use both. We test the options against your evaluation set and recommend the simplest one that meets the bar.

We choose per task, based on answer quality on your evaluation set, cost per request, speed, language support and where the model is allowed to run. Options include OpenAI GPT models, Anthropic Claude, Google Gemini, Meta Llama and Mistral, through services such as Azure OpenAI, Amazon Bedrock or Vertex AI. The model sits behind one interface, so it can be replaced later.

It depends on the problem, not on a fixed amount. What matters is enough history to cover the patterns the model must learn, including seasons and rare events, and reliable labels for the outcome you want to predict. We check this during the data review and tell you plainly if the data cannot support the target yet, and what to collect so it can.

It depends on your cloud, volumes, skills and budget more than on any single product. Snowflake, Databricks, BigQuery and Amazon Redshift all work well for most companies, and PostgreSQL is enough for many. We compare the options against your requirements and existing contracts, and design so the transformations, written in SQL with dbt, stay portable.

Yes. We use the ERP’s supported extraction methods, such as its APIs, export services or change data capture from a replica, rather than heavy queries against the live database. Loads are scheduled outside peak hours where needed. For SAP, Oracle, Microsoft Dynamics 365, NetSuite and Odoo we follow each vendor’s recommended approach.

Only for decisions that cannot wait, such as fraud screening, stock availability or payment status. For most reporting, loads every hour or overnight are enough and cost far less to run. We use streaming with Apache Kafka or change data capture where real time is needed, and batch where it is not, and we decide per use case with you.

Most structured and semi-structured business documents: supplier invoices, credit notes, receipts, bank statements and advices, purchase orders, delivery notes, customs and shipping documents, claims, application forms and identity documents. Handwriting, poor scans and unusual layouts lower accuracy, which is why we measure on your own samples before agreeing the scope.

No. Robotic process automation copies clicks on a screen and breaks when the screen changes. We read the document with document AI, check it with business rules and post through the ERP’s supported interfaces. Where a system has no interface at all, screen automation can be a last resort, and we say so when we use it.

We post to SAP S/4HANA, Oracle NetSuite, Microsoft Dynamics 365, Odoo and Sage, and to custom and workflow systems, through their APIs, import services or integration platforms. Posting follows the same approval rules your team uses today. Naming a product here does not mean a partnership with its vendor.

We start from what your team can run and hire for, what your other systems use, and what the software must do. For most business software that means a mainstream language such as TypeScript, Java, C# or Python, a relational database such as PostgreSQL or SQL Server, and the cloud you already use. We avoid niche tools unless they solve a real problem, and we record each choice and its reasons.

We use React with Next.js for most new applications because it supports server rendering, has strong tooling and is widely known by engineers. We also work with Angular and Vue, and we continue in the framework you already use when that is the sensible choice. The decision depends on your team’s skills, what the application must do and what you will maintain afterwards.

Yes. We keep every piece of text out of the code so it can be translated, and we lay out pages with logical properties so they mirror correctly for right-to-left languages such as Arabic. Dates, numbers and currencies follow each locale. We plan this from the start, because adding a second language to an application built for one is far more work.

Native apps in Swift and Kotlin give the fullest access to device features and the closest fit to each platform. Cross-platform apps in React Native or Flutter share most of their code between iOS and Android, which lowers the cost of building and changing them. We recommend native when the app depends heavily on the device, such as payment hardware or complex media, and cross-platform for most business and consumer apps.

Yes, where the journeys allow it. We store the data the user needs on the device, encrypted, and queue their changes until the connection returns. Sync rules decide what happens when the same record changed in two places. We design those rules with you, because they are business decisions as much as technical ones.

Usually the one you already use, unless there is a clear reason to change. Amazon Web Services, Microsoft Azure and Google Cloud all run enterprise workloads well. The deciding factors are your existing contracts and skills, the managed services you need, data-residency rules and how your other systems connect. We work across all three and keep provider-specific code to the places where it is worth it.

We use the tools that fit your stack and your team: Playwright or Cypress for web end-to-end tests, Appium for mobile, Jest, JUnit or pytest for unit tests, Postman for API checks, k6 or JMeter for performance and OWASP ZAP for security scans. We keep the tests in your repository and in your engineers’ language where we can, so they can maintain them.

We use the partner’s test environment or sandbox where one exists, and simulators where it does not, so tests can run on every change without depending on a third party. Test data covers the unhappy paths: rejected payments, timeouts, duplicate messages and partial failures. End-to-end checks confirm that totals reconcile across systems, not only that each call returned a success.

Yes. Right-to-left design is more than flipping the screen. Navigation, progress indicators, charts and icons that imply direction need mirroring, while numbers, logos and media controls usually do not. Arabic text needs its own typeface, size and line height. We design both directions together and review them with native readers.

A design system is a shared set of colours, type, spacing and components, with guidance on when to use each, kept in step between design files and code. You need one when several teams or products must look and behave consistently, or when a product will grow for years. For a single small tool, a lighter component library is often enough.

When the old core is stable and correct but hard to reach. Modern APIs in front of it let new channels, partners and products use its functions without touching its internals, at far lower risk than replacing it. We recommend replacement when the system blocks change, cannot be secured or can no longer be staffed.

We work with the stacks many business systems were built on, including older versions of Java and .NET, relational databases such as Oracle Database and SQL Server, SOAP services and file-based interfaces. For rarer platforms we assess the code first and tell you plainly whether we have the skills, or whether a specialist should join the team.

We work with SAP S/4HANA and SAP Business One, Oracle NetSuite, Oracle Fusion Cloud ERP, Microsoft Dynamics 365 Finance and Supply Chain Management, Dynamics 365 Business Central, Odoo, Sage Intacct and Sage X3, as well as custom and older systems. For each we use the interfaces the vendor supports, so upgrades do not break the integration. Naming a product does not mean a partnership with its vendor.

Not always. A few stable flows between two systems can be direct API calls. Once several systems exchange data, or you need mapping, queues and monitoring in one place, middleware such as MuleSoft, Boomi or Azure Logic Apps usually pays for itself. If you already own one, we build on it. We set out the trade-offs, including licence costs, before you decide.

We work with the ISO 20022 messages banks use for corporate payments and reporting: pain.001 for payments, pain.002 for status, and camt.052, camt.053 and camt.054 for account reports. We also handle the SWIFT MT940 and MT942 statements many banks still send. For transport we use host-to-host SFTP, EBICS where banks offer it, and bank APIs. Each bank has its own variant of each format, so we build from the bank’s implementation guide, not from the standard alone.

We connect banks to SAP S/4HANA, Oracle NetSuite, Oracle Fusion Cloud ERP, Microsoft Dynamics 365, Odoo and Sage, and to treasury and custom systems. Some ERPs have their own bank communication modules. Where they do, we configure and extend them rather than build around them. Naming a product here does not mean a partnership with its vendor.

Yes, where the acquirer or processor offers it. ISO 8583 is a framework rather than one format: each acquirer publishes its own specification of fields, message types and network management. We build from that specification, handle authorisations, reversals and advice messages, and test every response code. Where a gateway offers a modern API in front of the acquirer, we often recommend that instead.

We integrate EMV chip and contactless terminals through the protocol their provider supplies, usually a local or cloud API between the POS and the terminal. The terminal and its payment application are certified by the provider, so we integrate with them rather than change them. We confirm the exact models and protocols with you and the provider at the start.

It depends on how many connections you have and who will run them. An integration platform such as MuleSoft, Boomi or Azure Logic Apps gives you ready connectors, mapping and monitoring in one place, at a licence cost. Custom services give you full control and no licence, but you maintain more code. We compare both for your case and build on a platform you already own.

We read each partner’s published limits and design around them: batching requests where the API allows it, caching data that rarely changes, spreading scheduled jobs and backing off when the partner signals that a limit is near. Monitoring shows how close each flow runs to its limit, so growth does not turn into failures.

Usually not. Most banks gain more by wrapping the core in well-defined APIs and building new products and channels as services around it. That keeps the system of record stable while the customer-facing parts change faster. Where a core really has to be replaced, we plan the migration in stages, with both systems reconciled until the old one is switched off.

Yes. We build services that create, validate and read ISO 20022 messages, both for corporate payments and reporting, such as pain.001 and camt.053, and for the interbank messages used by instant and high-value payment systems. Each scheme and bank has its own rules, so we work from their implementation guides and test in their test environments.

Yes. We combine rules your analysts can read and change with machine-learning models trained on your own data, and we explain why each alert was raised. Alerts go to a case queue where analysts decide, and their decisions feed back into the rules and the models. Where you already use specialist screening providers, we connect them.

The store keeps selling. Sales are stored locally and sent when the connection returns, each with a unique identifier so that nothing is posted twice. Price and stock updates queue up in the same way. Operations can see which stores are behind and by how much, so a long outage is noticed straight away, not discovered at month end.

We integrate POS platforms through whatever they offer: cloud APIs, store servers, database exports or files. Before we estimate, we review the POS documentation and a sample of its data, because that decides the approach. Naming a POS platform or an ERP on this site does not mean a partnership with its vendor.

Yes. We build and maintain EDI flows in EDIFACT and ANSI X12, over AS2, SFTP or a value-added network, for orders, despatch advice, invoices and status messages. We also translate EDI into APIs and events, so newer systems do not need to read EDI themselves, and we test each flow with the trading partner before it goes live.

We put one carrier layer between your systems and the carriers. Your systems book, label and track through a single interface, and the layer maps each request to each carrier’s API or file format. Adding a carrier then means adding one mapping and its tests, not changing every system that ships. Rates, labels and tracking events come back in one format.

Yes. We extend existing systems through their APIs, message interfaces or databases, and add mobile tools and integrations around them. If a system has reached its limits, we plan a staged replacement, with both systems running until the new one is proven.

Yes. We build interfaces that send and receive HL7 v2 messages, such as admissions, orders and results, and services that expose or consume FHIR resources. We map local codes to the terminologies your partners expect, and we test with their test systems before anything goes live.

Usually, yes, through the interfaces its vendor provides: HL7 v2 feeds, FHIR APIs or an integration engine. Some vendors require registration or approval before an integration goes live. We review the vendor’s documentation early, because it decides the scope and the plan.

We design to WCAG 2.2 AA from the first prototype, write in plain language, and test with keyboards, screen readers and magnification. Automated accessibility checks run in the delivery pipeline, and before major releases we test with people who use assistive technology.

Yes. Many public services depend on long-lived systems. We connect to them through their existing interfaces, files or databases, and put a modern API in front of them where that helps. If a replacement is needed, it happens in stages, with both systems running until the new one is proven.

Not if it is built the right way. We use the ERP’s supported extension points, such as APIs, events and extension frameworks, and keep custom code apart from the standard product. Each extension is documented and tested, so it can be checked against a new release before you upgrade.

We work with SAP S/4HANA and SAP Business One, Microsoft Dynamics 365 Finance and Supply Chain Management and Business Central, Oracle NetSuite, Oracle Fusion Cloud ERP, Odoo, and Sage Intacct and Sage X3. Naming a product does not mean a partnership with its vendor. Tell us your version and modules, because they decide the integration options.

Yes. We design integrations to handle several legal entities, currencies, banks and tax rules from one platform, with the settings for each entity held as configuration rather than code. Adding an entity then means adding configuration and tests, not a new integration.

The bank usually decides. Host-to-host SFTP is the most widely offered channel for corporate payment files. EBICS is common with banks in Germany, France and neighbouring countries. Bank APIs suit real-time balances and instant payments where the bank offers them. Many companies use more than one, and the integration layer hides the difference from the ERP.

Where the bank offers both, camt.053 carries richer, structured remittance data, which makes automatic matching more reliable. MT940 is still widely used and works well for many cases. We can take both, convert them into the same internal model, and move each bank from MT940 to camt.053 when it suits you and the bank.

Usually as events close to real time, because stock and sales figures are then current during the day. Some ERPs or licences make frequent postings costly, so the layer can also group events into summaries per store and period. We choose with you based on what decisions need current data and what the ERP handles well.

The design works with any POS that can export transactions through an API, events or files, and with ERPs such as SAP S/4HANA, Oracle NetSuite, Microsoft Dynamics 365 Business Central and Odoo. We confirm the interfaces of your specific POS and ERP at the start. Naming a product does not mean a partnership with its vendor.

The acquirer is the bank or licensed institution that processes card payments for you and pays out the money. The gateway is the technical service in front of it that accepts requests from terminals and checkouts, tokenises cards and routes them. Some providers are both. The design works either way and keeps the two roles clear.

No. ISO 8583 defines a structure, and each acquirer or network publishes its own specification of fields, message types and codes. That is why we build from the acquirer’s specification and run its certification tests. A gateway API in front of the acquirer hides these differences, which is often simpler for retailers.

An aggregator gives you many banks through one API and handles each bank’s differences, at a per-call or per-connection cost. Direct connections give more control and can suit a small number of important banks. Many products start with an aggregator and add direct connections later. We compare the options against the banks and countries you need.

Coverage depends on the region’s rules and the banks’ APIs. The European Union and the United Kingdom have broad coverage under PSD2 and the UK Open Banking Standard. Elsewhere coverage varies, and aggregators fill some of the gaps. We check coverage for the banks your customers use before you commit to a design.

Not for most corporate treasury work. Host-to-host channels handle bulk payment files and full statements for your own accounts. Open banking suits customer-facing products, real-time balances and single payments. Many businesses use both: host-to-host for their own payment runs and open banking for their customers.

Any service with a documented API or file interface. Typical examples are CRM platforms, carriers and logistics providers, marketplaces, e-invoicing and tax platforms, payroll, KYC and identity providers, and trading partners who exchange EDI documents over AS2. We review each partner’s API, limits and test environment before we commit to a plan.

Once several partners are connected to one ERP, a platform such as MuleSoft, Boomi or Azure Logic Apps, or a set of custom services built on a message queue, keeps mapping, retries and monitoring in one place. With one or two partners, direct connections can be enough. We set out the trade-offs, including licence costs, for your case.

XSIS is KONG GROUP’s technology company. We design, build, integrate and run software for enterprises: AI and data, custom software, web and mobile, cloud, and the integrations that connect ERP systems to banks, POS and third parties. Fintech is our lead industry. We deliver through our own in-house engineers and vetted outsourced teams, under one set of standards.

Our headquarters is in San Francisco, USA. We also have offices in Hong Kong, in Tallinn, Estonia and in Dubai, UAE. We agree working hours and meeting times with each client at the start, so the overlap suits your team.

Tell us what you need on the contact page and choose a time slot that suits you. Our team will call you within 24 hours during your preferred time slot. In that first conversation we ask about your systems, constraints and timing, and suggest the way of working that fits. If there is a match, a written proposal follows.

Yes. Naming a product on this site does not mean a partnership with its vendor, and our recommendation follows your requirements, skills and budget, including keeping what you have when that is the better answer. If we would like to deliver the work ourselves, we say so openly, and the plan is written so any competent team can deliver it.

Fintech is our lead industry. We build digital banking and wallet apps, payment and settlement services, lending platforms, wealth reporting and insurance journeys, and we connect them to banks, card processors, KYC providers and ERP systems. We do not publish client names without their consent, so we show our experience through the systems and standards we work with, and in technical conversations with your architects.

Yes. We respond to tenders and framework requirements, and we can work to fixed or staged scopes with written acceptance criteria. We provide the documentation buyers usually ask for, such as security descriptions, delivery plans and named roles, and we state only what we can evidence. Where a framework sets its own terms, we work within them.

Our focus is extending and integrating ERP systems rather than running full implementations. We often work alongside your implementation partner and take on the integrations, data migration, custom extensions and the apps around the ERP, so the core project can stay on its plan.

Account information and payment initiation are regulated activities in many countries. Either your company holds the authorisation, or you work through a licensed provider that holds it. Which applies depends on your country and use case, and your legal and compliance advisers should confirm it. We build the integration for whichever route you take.