Our client provides concierge services to global companies. The integration has been built for one of their largest partner a well known international Bank.

Their customers can now use their phones to call in to a secure phone line, submit their credit card number and get redirected automatically to a relevant (even favorite, if they've told us who that is) Lifestyle Manager, who will be presented with relevant info about the caller:

• Their identity (name)

• Membership Status (eligible or not) and Level (VIP tiers) with the Bank

• Their number of Loyalty Points

As a result, eligible members now have more personalized interactions with their Lifestyle Managers, and can be served more efficiently. They're now also able to use their Loyalty Points to pay for travelling, including the newly launched Elite points (up to 6 in a year) for specially tailored deals.

We have created a unique .NET-based test automation framework with Selenium for testing an enterprise-level web application, a self-concierge platform from the frontend and backend point of view as well. It includes an almost exhaustive UI functionality test scenario set covering most of the user behaviours as scenarios and validating content against multiple sources, including language content, database validation, and content management system integration.

We can run tests on our own CI system, in parallel threads (to reduce execution time), and on mobile and different browsers as well. On the backend side, we can validate the REST applications and GPRC applications in numerous different ways, also we regularly do performance tests.

Due to this effort, we significantly dropped the missed bug deployment during regression, regression effort, and time.

We've implemented a solution to segregate client-related data when needed.

Our clients regularly send update packs to us about their customers, which we store locally. Some clients are concerned with the security of their data, and don't want their data stored in the same place as others.

For them we've implemented a Data Segregation solution, which splits out Personal Identifiable Information (PII) into a separate, secure, lightweight database. These segregated DBs and the main DB share some primary keys for identifying customers, along with any related PII data they need.

Our system can intelligently pick which database to use, based on which client's data we need to load.

This project is an automatic process, which parses a large number of Microsoft Exchange mailboxes, automatically picking up any incoming mails.

The mailboxes themselves are where customers generally send their requests to Lifestyle Managers about what they want to do next, or following up on previous quotes or bookings.

The Request Automation project picks each of these emails up, scans them, identifies the customer, their open jobs in our systems, creates new interactions in our internal CRM, and finally, forwards the emails to Genesys Cloud with the processing results, from where Lifestyle Managers have all necessary information to start serving their requests.

This project is essentially the email counterpart to the Bank integration project.

Since our client's working with credit cards, and other sensitive information, PCI-DSS compliance is important to be trusted in the Credit Card Industry.

The core systems were already compliant, and they go through periodic verifications, to ensure we continue to be compliant.

We've achieved compliance with a technique called Tokenisation. This is a process by which all sensitive information first goes through a tokenisation proxy, before reaching any of our internal systems. This proxy is responsible for replacing (and storing) sensitive info (card numbers, CVVs, etc.) with "Tokens". These tokens are string, which are randomly generated, and share no resemblance with the original sensitive information, so they cannot be "cracked". Sensitive information is encryped and stored in the Tokeniser DB, and then mapped to their appropriate token. Only the Tokenisation Service has access to this encrypted database.

Once all sensitive data is replaced with tokens, all other interactions that happen with these tokens no longer fall under PCI, since they're not actually sensitive data.

With this system, we've effectively minimized the PCI zone (the area, which needs periodic verification) to a single service and an encrypted database.

OpenTelemetry is a collection of tools, APIs, and SDKs, which can be used to instrument, generate, collect, and export telemetry data (metrics, logs, and traces) to help analyzing software’s performance and behavior.

In this project we investigated the options to introduce OpenTelemetry standards in the whole ecosystem including multiple stacks (frontend, backend and 3rd parties) on different platforms, to be able to track traces and metrics in a standardized way. The common solution that was built, is not only following the strandards, but provides an easily adaptable way to apply them for any newly built services. It gives us abilities to measure any custom phases in the processing flow in application services, which provides us tracing data and also custom metrics about processing durations.

By using it, we are able to track how a single request - sent from the frontend - travers through the system via service layers or event bus messages, how the application-internal phases are separated and how these end up in external systems like databases, cloud services or any 3rd parties. The traces can also be used to analyze where bottlenecks are as all the tracing data is forwarded to AWS X-Ray for deep analysis, and there are also Grafana dashboards built upon the built-in and custom metrics generated in applications.

Our partner works with multiple global clients, each of them have their own customers around the world. Many clients come to us with specific requirements related to the security of their data. The Data Segregation project handles some of these - for others, we use specialized permissions to control data visibility.

These permissions are multi-faceted:

We use functional permissions to control what actions the Lifestyle Managers are allowed to do - these are your generic permissions.

And we use corporate permissions to control what data the Lifestyle Managers have access to - this is our innovation.

We store all our data in relation to the clients, their programmes (products), the regions they operate in, and the languages their customers speak. With this structure, we can enforce specific rules to what each Lifestyle Manager is allowed to see and do. This also allows us to comply more easily to certain regional requirements.

Example: USA requires that only US citizens have access to other US citizens' data. We can enforce this with a permission-based region lock - only allowing US Lifestyle Managers to see US customers' information.

Event bus is an architectural component that implements the publish-subscribe communication pattern to be able to publish specific events by any components and to able to subscribe any component on any event types they are interested in. In the microservice architecture we built a common and generic event bus layer that strengthens the decoupling between the components. In this project we investigated the requirements by architects and the needs by the system, to build an easily adaptable solution into the architecture so we can attach the microservices to the event bus - doesn't matter they are producers or consumers. We chose MassTransit which provides a feature-rich, message broker-agnostic solution that can work upon multiple service brokers. Our solution also hides MassTransit as a dependency and with a few lines of initializer code, the component can be connected to the event bus and event publishing or consuming can be started without any further development.