Industries

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.

Read more: Fintech and financial servicesLink to this question

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.

Read more: Fintech and financial servicesLink to this question

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.

Read more: Fintech and financial servicesLink to this question

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.

Read more: Retail and POSLink to this question

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.

Read more: Retail and POSLink to this question

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.

Read more: Logistics and distributionLink to this question

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.

Read more: Logistics and distributionLink to this question

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.

Read more: Logistics and distributionLink to this question

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.

Read more: HealthcareLink to this question

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.

Read more: HealthcareLink to this question

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.

Read more: Public sectorLink to this question

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.

Read more: Public sectorLink to this question

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.

Read more: Manufacturing and enterprise ERPLink to this question

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.

Read more: Manufacturing and enterprise ERPLink to this question

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.

Read more: Manufacturing and enterprise ERPLink to this question