Lusis Payments | Innovative Global Payments Software and Services
FR (+33) 1 55 33 09 00  -  USA ​(+1) 415 829 4577 - CA ​(+1) 416 979 7800 - UK (+44) 20 3398 5582
  • Home
  • TANGO
  • AI FRAUD
  • LITEPOS
  • SOLUTIONS
    • TANGO VIDEOS
    • LITERATURE
  • BENCHMARKS
    • USER PROFILES
  • ABOUT
    • PARTNERS >
      • HPE GreenLake
    • VIDEO
    • EVENTS
    • PRIVACY
  • WEBCAST
  • Contact
    • CAREERS >
      • JOBS-UK
      • JOBS-FRANCE
      • JOBS-NA
      • JOBS-LA
      • JOB APPLICATION
  • NEWS
    • Market Insights

HAPPY NEW YEAR! 2022 HIGHLIGHTS

1/18/2023

 
Picture

As we begin the New Year, we’d like to express our deepest gratitude to all our clients, partners and teammates for making it an exceptional year.
 
We would like to highlight four major milestones in 2022:
 
  • Lusis formed a partnership with Mastercard Access which expands payment platforms for Mastercard while allowing Lusis to connect to previously unreached payment flows, both MA and non-MA processed payment flows and services. The partnership also creates additional market reach for MC and expands our North American customer base by allowing multiple schemes, networks and services. Customers benefit with simplified access to more networks, reduced time to market, costs, integration resources, and Mastercard services via API.
 
  • Another major highlight includes a strategic investment agreement with Bank of America. This agreement provides Bank of America a minority shareholding in Lusis Payments and an appointed representative on the Lusis board. Lusis technology is playing a crucial role within Bank of America’s payments services. The TANGO suite from Lusis Payments is a leading retail payments solution for acquiring, routing, switching, authentication, authorization, and fraud prevention. “We are proud to serve Bank of America’s payments needs with our TANGO software. This latest agreement deepens our relationship and ensures that Lusis Payments remains on the forefront of global Retail payments innovation”  -Philippe Preval, CEO Lusis Payments. Bank of America is one of the world’s leading financial institutions, serving individual consumers, small and middle-market businesses, and large corporations with a full range of banking, investing, asset management and other financial and risk management products and services.
 
  • 2022 saw banks giving significant attention to their “Cloud Strategy”, whether it be in the planning stages or early implementations. The question that banks need to ask themselves concerning their Cloud Strategy is what software investments are required to improve operational efficiencies, streamline the customers’ journeys, and increase competitive agility. Simply shifting the same tired, poorly integrated ‘software blobs’ into the cloud may save a few bucks, but it does very little to Transform their business. With our proven cloud-based TANGO deployments, Lusis has seen a dramatic increase in interest for our Cloud solutions that improve an organization's operational efficiencies and customer experiences. Our partnership with HPE as their chosen payments solution for the GreenLake cloud platform further indicates our expertise in the cloud space.
 
  • Lusis continues to expand our technical resources around the globe with a new office in Mexico and the expansion of our Toronto office.  

As we look forward for 2023 which includes many new announcements to share, we would like to wish all of our customers, partners and staff a Happy and Prosperous New Year!!

Banking on the Cloud

11/22/2022

 
Picture
By Dave Smith - Consultant, Lusis Payments
 
It was John Gage of Sun Microsystems who coined the phrase, “the Network is the Computer” - way back in 1984.  Understandably, this phrase was originally more of a vision than the reality. However, the ensuing 38 years of computing development has generated incredible progress.  With the advent of Cloud computing we now live in a world where on-demand computing infrastructure can be readily purchased and deployed within any geographic region.
 
Surely we can agree that the computer industry has fully delivered Gage’s historic vision. 
 
However, putting aside the numerous technical achievements we also need to consider the functionality of the software itself.  A recent banking experience provided a sobering reality check and several points to ponder.
 
My “customer journey” started when I needed to update the registered address on my business account.  This was accomplished easily enough using the online banking facilities.  The real challenges started when I tried to change the address on the associated credit card. I had naively assumed that this could also be done online - given that both my business account and credit card were issued by the same bank.
 
After a lengthy wait in the phone queue, the support agent for the credit card team informed me that the address change for account had not updated on her system yet. Furthermore, it could take up to 3 business days to complete. Additionally, it wasn’t clear whether I would automatically receive a notification message once the credit card address was changed. What!?
 
So much for the “seamless customer journey” ideas that I hear being preached at banking conferences.      
 
Today, banks are rightly giving significant attention to their “Cloud Strategy”, whether it be in the planning stages or early implementations.  The recent acquisition of Cloud payments specialist, Renovite, by JPMC demonstrates the importance some banks are assigning their Cloud strategies. 
 
In my view, a cloud strategy should not become overly distracted by the technology itself.  The staggering levels of investment being injected by Microsoft, Google, Amazon, and others, will ensure that the Cloud will consistently become better and better.
 
The real question that banks need to ask themselves concerning their Cloud Strategy is what software investments are required to improve operational efficiencies, streamline the customers’ journeys, and increase competitive agility.
 
Simply shifting the same tired, poorly integrated ‘software blobs’ into the cloud may save a few bucks. It might even win the CIO some Brownie points.  But it will do very little to Transform their business.
 
Hopefully, it is the Transformative potential of the Cloud that will guide the banks’ strategies beyond the short term cost gains.

Contact Lusis Payments when developing your Cloud strategy for solutions that improve your organization's operational efficiencies and improve customer experiences.

NEW: TANGO V8.1 with Cloud-Native Support

8/25/2022

 
Picture

TANGO is the world's most performant Retail Payments solution with benchmark tests demonstrating 10,000 transactions per second. Built using a micro-services architecture, TANGO is also feature-rich and easily extensible. Backed by Lusis' proven track record it is not surprising that more and more organizations are swapping out their legacy payments infrastructure for TANGO.

TANGO is the culmination of decades of crafted engineering that ensures the maximum operational performance and reliability as well as the most affordable cost of ownership. For example, TANGO includes a Self-Monitoring and Auto-Spawning feature whereby a suite of timers can be configured to monitor the processing time for specific events. By comparing the real-time measurements against the defined norms TANGO can immediately identify bottlenecks as soon as they occur. TANGO can also be configured to automatically spawn new instances of the affected micro-service or process thereby ensuring the required throughput is maintained.

TANGO uses the Docker containerization platform and a typical deployment uses the 5-Container model shown below.

Picture
Significantly, the container boundaries are defined to simplify manageability. For example, the gateways and firewalls are combined in a
single container to simplify PCI certification tasks. Equally, the monitoring and other tools are located in a dedicated container to ease
system evolution.

This approach has numerous benefits, not least of which is that it is well proven and supports the easy and secure use of cloud infrastructure. However, in this model, container creation is still a manual process. Consequently, Lusis has expanded TANGO's container model to deliver the full elastic scalability advantages of a cloud-native environment.

TANGO Cloud-Native Support
Introducing cloud-native support to TANGO was principally achieved through the adoption of a “many-containers” model and the addition of a container orchestration component. TANGO was already a containerized application (using Docker) so this was a relatively simple step.

Given that cloud technologies are continuing to evolve, Lusis recognized the importance of providing customers with a choice of technologies. Specifically, Lusis has validated TANGO with both Kubernetes and OpenShift as the container orchestration layer. Additionally, TANGO has been certified to run on the cloud
infrastructure of Azure, Amazon, and Google.  READ MORE
Vertical Divider
payments cloud software
Download to read the rest of the document.
Submit

TANGO: FAST-TRACK TO CLOUD PAYMENTS

10/1/2021

 
Picture

​In today’s Retail Payments market there are two critical success factors; scale your business for revenue growth and optimize your operations for cost savings. This is a simple and well-known adage, but it masks a myriad of complexities. The inherent difficulties in meeting stringent regulations, reducing costs, and responding to rapidly changing market needs has driven legacy payments systems to breaking point.

Changing payments platforms represents a multi-decade investment commitment with serious repercussions in the event of failure. However, no amount of “just hanging on” will avoid the inevitable and it will only result in a loss of opportunities to more nimble competitors. With so much at stake it is understandable that management teams are cautious about changing payments platforms – but perhaps to their own detriment?

Fortunately, a clear way forward is emerging – TANGO by Lusis Payments.
TANGO is used by 4 of the top 10 Retail Banks to power their payments strategies, as well as a multitude of banks and processors around the globe. TANGO’s advanced micro-services technology and pedigree customers are clear advantages over its rivals. Additionally, TANGO’s functional richness, and unique configuration flexibility, guarantee ongoing business advantages.

A recent TANGO Cloud deployment provides a great example of these advantages. 
An existing Lusis customer successfully redeployed their legacy DCC service into the Azure cloud using TANGO. As a result, the customer achieved substantial cost savings and vastly improved operational efficiencies. The entire service was implemented using standard product code and was delivered for acceptance testing within 3 months.

TANGO was deployed in the Azure cloud with Azure SQL using TANGO’s built in Active-Active configuration to ensure the highest availability. External links were used to connect to the bank’s on-premise HSMs and Card Association networks to leverage existing investment. TANGO’s tokenization support protects the card details and the Azure security was augmented with the bank’s own measures to achieve PCI certification. 

    contact us for more info

Submit

Tango V8 – An Implementation of Microservices Architecture

6/22/2020

 
Picture
Click HERE to view the original article posted on "The Connection" magazine
Established in France in 1999, Lusis has offices throughout Europe and North America with customers globally. In 2010, Lusis Payments was created to focus on the payments industry. Lusis is best known for its TANGO solution, an online transaction processing engine for mission-critical 24×7 solutions including payments, retail, loyalty, finance, fraud, utilities, and transport. TANGO delivers performance, availability, and scalability, with a rich set of functionalities, all from a single architecture. TANGO is built on a highly performing micro-service architecture providing agile delivery for business needs. Lusis has also made significant advancements in Data Science, Artificial Intelligence, FX Trading, ISO 20022, Fraud and Blockchain.

This article is an introduction to TANGO version 8, a major upgrade that provides full microservice integration and complete Cloud capacities.

Introduction
Our broadly used Tango software is an implementation of a microservice architecture.  Tango was not initially designed to be “microservice”, it was more properly designed to implement a transactional, mission critical, Service Oriented Architecture “that works” (SOATW!). By “that works” I mean, performant, scalable, avoiding contentions and anarchic leeway and sustainable. It is clear that to make it sustainable, a SOA system must include major concepts: a data bus or universal messaging layer to anarchy (meaning the ability to define as many interfaces than relations between services) and a load-balancer in order to avoid contentions or stress points. Some state that these 2 concepts are the key differences between SOA and microservice. However, the definition of microservice is not so clear and sometimes it is nothing more than: “it is not a monolithic architecture”. So, the first thing we will do is define it, then we will outline what applies and what does not apply in Tango and finally we will present Tango v8.

What is a microservice architecture?
A microservice application is a collection of autonomous services, each of them doing one thing well, and when combined, work together to provide a global service. Instead of a single complex system (monolithic architecture), the aim is to build and manage a set of relatively simple services that might interact in complex ways. These services collaborate with each other through a messaging protocol.
The idea is quite simple. Having a collection of little ships instead of a huge one. That metaphor is not totally wrong. Lots of little ships are easy to maneuver, if one is delayed the others can progress. However, you can quickly cover more space with your multiple ships and if one is sunk (bad feature, bad design…) the others can still fight. Of course, there are some intrinsic difficulties: first a light fleet requires more coordination, second it is not as easy to make it a robust battleship.
Anyway, microservices promise a better way to sustainably deliver business impact. Rather than a single monolithic unit, applications built using microservices are made up of loosely coupled, autonomous services. Building services that do one thing well avoids the inertia and entropy of large applications.

Properties of microservices are:
  • A single microservice should be highly cohesive: it should be responsible for some single capability within an application. Likewise, the less that each service knows about the inner workings of other services, the easier it is to make changes to one service — or capability — without forcing changes to others.
  • A microservice owns its data store, if it has one. This reduces coupling between services because other services can only access data they don’t own through the interface that a service provides.
  • Microservices themselves, not the messaging mechanism that connects them nor another piece of software, are responsible for “choreography” and collaboration — the sequencing of messages and actions to perform some useful activity.
  • Each microservice can be deployed independently. Without this, a microservice application would still be monolithic at the point of deployment.
  • A microservice is replaceable. Having a single capability places a natural boundary on size; likewise, it makes the individual responsibility, or role, of a service easy to comprehend.
An exception to our design are the concepts (load balancer and Databus) that are introduced above, which are not accepted by all publications, however, the differences with SOA are more shades than key points. For instance, microservices are responsible for coordinating actions in a system while this can be external in SOA (complex orchestration can be externalized). Others say that Microservices design is driven by business and SOA design is driven by technique (technical layers…). This is an expert’s debate.

Microservices applications scale by:
  • Adding instances of microservices. This is of course standard with microservices.
  • Deploying multiple, identical instances of the application (like monolithic applications. On this point there is no specific advantage for microservices applications).
  • Horizontal data partitions (ex: partitioning on account numbers). In theory this can be used both for microservices and monolithic applications. In practicum this is much more efficient with microservices.
So, a microservices application can scale along the 3 axes, as they have been defined by Abbott and Fisher in The Art of Scalability.

Five architectural principles structure microservices developments:
  • Autonomy: each service operates and changes independently. They are loosely coupled and can be deployed independently (Services can be developed in parallel, by different teams…).
  • Resilience: microservices is a mechanism for isolating failure.
  • Transparency: system must be transparent as a global service is provided by multiple. microservices, in case of malfunction, it is imperative to know what fails and why.
  • Automation: as a global service is provided by multiple microservices it is important to integrate deployment practices at very early stage.
  • Alignment: aligning teams and developments around business concepts.


As mentioned above there are specific challenges and risks:
  • The risk of dilution with too many entities (i.e. “nano-services”) providing nothing.
  • The risk of having contracts and boundaries defined “one to one” with no global view.
    • The combination of these 2 risks leads to a baroque or mannerist architecture where you lose your way.
  • The risk of having data everywhere and in every format.
  • The risk of having developments with no vision or care of performance, security, or consistency.
The architecture demands management and vision.

Tango. What we implement, what we do not.
First, we at Lusis produce mission critical systems or applications that can’t fail. They must never lose a single transaction, never lose an order, never tolerate an outage, etc… This is not the standard world of the “web apps”. This is such an important difference that only those who are in the mission critical business can really understand it because failure of these mission critical systems could be the deciding factor between a managing director keeping their job or not.

As with Lusis Tango, the HPE Nonstop was built on this same concept/mantra.  Every component within the Nonstop framework is designed to never allow failure.  Which is the reason why the HPE Nonstop has been the preferred hardware platform of choice for many large banks and financial institutions as well as other mission critical businesses for many years.

Lusis Tango runs successfully on the HPE Nonstop.  Lusis Payments has several customers realizing huge performance advantages running Lusis Tango on the HPE Nonstop.  In addition, our systems are highly scalable and available which is imperative in the mission critical environment. Second, we are not realizing apps, projects or custom development. We are designing and developing a software that has to be economically competitive. This means for instance, that all development must look like the others, be written in the same way, with the same style, as we can’t afford “specialist developer” for this work.  This is close to the CBSD model of development that I won’t expound upon here but to say it is fundamental in our development approach.

Third, we provide an IT infrastructure that will last for many years into the future.  So, it must be designed to live and scale, change, and mutate for 10, to 20 years or more. The infinity of an IT time scale.

Therefore, we have some very specific requirements:
  • We are responsible and accountable for the performance and high availability of the system. With that in mind, we cannot delegate the data transport to a third-party application. We will not put ourselves in a position to blame a third party.  Therefore, we must be responsible for all aspects the system.
  • Microservices development teams can’t negotiate the contracts and the boundaries. This is done by the Tango platform, the Tango API to access the Databus, the Tango Databus, and the Tango data dictionary. Of course, this is evolving and changing but at a different pace and bearing the global aim in mind.
  • A microservice does not own its data store for many reasons.
    • First because we want to use the data and it is easier if the data are all in the same place.
    • Second because the data are more secure and encrypted.
    • Third because we export them to client’s data lakes or storage.
  • We are performance driven, so we don’t multiplicate the swapping between processes for the pleasure of beauty.

Having said that, a Tango application is clearly a collection of autonomous services, each of them doing one (or a few more) thing(s) well, that work together to provide a global service. They can be developed separately and deployed and run independently. A Tango application scales properly along the 3 axes that were mentioned above.

As we are providing software in a restricted number of business spaces these services can be grouped in “families of services” that are doing the same kind of things at a conceptual level. It is important because each “family” or sub-family, have its own technique and set of libraries, tools, and ways to improve productivity. For instance, in a payment system, services types are:
  • Exchanging data with payment networks: roughly converting external messages in the Tango bus and vice versa. Of course, a bit more complicated. We can imagine that dialing with Visa per se is not so far from dialoging with UPI (China) even if details are different. So, all the connections to payment networks (Visa, Mastercard, UPI, JCB, …), all the message connections with HOST systems (DDA & so on) are in the same family.
  • Managing devices requires dealing with a message protocol but at the other end you have a terminal with attributes, counters, local data, stop/start commands, etc. Having said that an ATM is an ATM, a POS device is a POS device.
  • Web services and APIs: this is similar to a messaging network like VISA or Mastercard at a conceptual level.
  • Business services: making decisions (authorize a transaction or not), detecting fraud and orchestrating complex multi-leg transactions. Business services are of course agnostic to any external data format as it is normalized in the Tango data bus.
  • Technical services: transporting, routing, logging and managing high availability. One of the key technical services is the Tango dispatcher that is in charge of technical routing and load-balancing.
The Tango application is a collection of autonomous services that are a combination of interfaces with payment networks, business services, technical services, etc.  All of them exchanging data via the set of APIs of the data bus and the dispatcher.

The studying of the Susan Fowler’s book Production-Ready Microservices was very useful to us as it allowed us to review and audit our Tango architecture from the criteria for Production Readiness that she defines. The review concluded that a strong majority of these criteria were met (95%). When we were observing that Tango was not matching one of those criteria it was either by mistake or by a decision. In that case, it was worthwhile to evaluate if this decision was still valid. For instance, we were not interested in implementing the capacity for a Tango application to auto-create instances of services if the software was indicating there were not enough of them. For this reason: as we could not push the wall, or create CPU unit, it was useless or even negative to create new instances that would have further disturbed the machine and worsened the situation. Of course, this is no longer true with the Cloud capacities.

From this review we deducted a list of Tango architecture features that constituted the base of the Tango Version 8 roadmap.

Tango Version 8
We will limit the presentation to the two most important changes that are creating a true disruption considering Cloud capacity.
Reviewing the “dispatcher”
As mentioned above the Tango dispatcher oversees the technical routing and load-balancing. This is a very robust, very efficient (microseconds to process), multi-instanced service. However, mixing these two functionalities has some drawbacks: the routing context is  in the dispatcher (timeout, multi-step rule, …), the dispatcher uses Tango events like a normal Tango service and therefore ,the dispatcher is not context free so can’t be easily “cloudified”.

The dispatcher will be split into two parts:
  • A routing library that contains all the message routing, timeout handling, failure handling code. This will be embedded in each routing consumer service.
  • A message router that allow routing messages between processes based of data provided in the messages itself.

When a Tango service sends an event (either a request or a notification), the destination is computed by applying the routing rules on the message. There are two cases:
  • The service is local (in the same process).
  • The service is not local (in another process).

When the destination service is local, the event is directly sent to the service using direct COM (a Tango process that knows each service composing it and can push directly the events inside a specific instance of a specific service), otherwise the message will be sent to the message router.

The message router will not be a “Tango service”, it will use a lightweight Tango process and exchange messages using an optimized binary protocol not using standard Tango messaging.

A typical event routing message will contain information about the sender, the target and the content. The message router will be completely agnostic about the message content, it will only use the routing data for delivery.

The message router gathers the list of connected services all the services are connecting to all message routers and keep the connection alive like is done with the dispatcher using the self-registering feature and when an event must be routed it will choose the “best matching target”.
Publish/Subscribe pattern has also been added for outgoing notifications:
  • When a notification is sent using a “publish” rule, no destination will be computed, instead an event type identifier will be sent to the message router.
  • When the “clients” services connect to the message router, they will announce their subscriptions (by reading their configuration) thus all the message routers will know the list of interested clients and when publishing an event, it will be sent to all the available interested registered services.

Microservice self-monitoring
This covers two new functionalities: ‘custom counters’ and ‘process/service auto-spawn’.

Custom counters can be defined to monitor the processing time for specific events (usually only the request/response/notifications are monitored regardless of the kind of message).  Now, a reference time can be defined for the event processing considered as a “normal” processing time for this kind of message for this microservice (ex: order creation on the OMS service).  Processing time is computed in real-time and when the service begins to get “overwhelmed”. If the processing time increases over a defined limit, then alerts will be triggered and logged allowing the system to monitor the problem as soon as it occurs and locate the failure directly.

Sometimes, the processing time may increase because the load is getting higher than usual (load peak) so the custom counters can also be linked to the “auto-spawn” feature. If defined inside the configuration, Tango will spawn automatically new instances of the microservice or process whenever the load is going over the predefined limit, allowing the Tango environment to automatically scale in function of the load.
A new microservice will also be added gathering processing times and health status from all the other microservices, allowing centralized monitoring and provide real-time health status information about the environment to a dashboard.

Full Cloud capabilities
In conclusion:
  • Adding a new node (or a new service) will auto-register all the services without having to explicitly configure them inside the Tango configuration.
  • The load may be balanced to the new node transparently.
  • The publish/subscribe pattern allows distributing messages without knowing all the recipients beforehand.

With these new features and its current capacities, Tango can be installed on elastic cloud instances and new nodes can be spawned if the load requires it.

Bibliography:
Microservices – Microservices in action by Morgan Bruce, Paulo Pereira
Microservices – Production-Ready Microservices by Susan J. Fowler
CBSD – An Introduction to Component-Based Software Development by Kung-Kiu Lau, Simone di Cola
Scalability – The Art of Scalability by Martin L. Abbott, Michael T. Fisher

    lUSIS nEWS

    The latest company and industry news from Lusis Payments.

    Archives

    February 2023
    January 2023
    November 2022
    October 2022
    August 2022
    July 2022
    June 2022
    April 2022
    March 2022
    January 2022
    December 2021
    November 2021
    October 2021
    September 2021
    August 2021
    June 2021
    May 2021
    April 2021
    December 2020
    November 2020
    October 2020
    June 2020
    April 2020
    March 2020
    January 2020
    August 2019
    July 2019
    April 2019
    March 2019
    February 2019
    January 2019
    November 2018
    October 2018
    August 2018
    July 2018
    June 2018
    May 2018
    February 2018
    November 2017
    September 2017
    July 2017
    June 2017
    May 2017
    April 2017
    July 2016
    June 2016
    April 2016
    March 2015
    February 2015
    January 2015
    December 2014
    September 2014
    August 2014
    July 2014
    November 2013
    October 2013
    September 2013
    December 2011

    Categories

    All
    10k TPS
    2017
    2018
    2019
    2020
    2021
    2022
    2023
    4500 TPS
    AGILITY
    Apple Pay
    Article
    Artificial Intelligence
    ATM
    ATM Machines
    Atm Software
    Banking
    Bank Of America
    Base24
    BAYESIAN MODEL
    BENCHMARK
    Blockchain
    Blog
    CANADA
    Case Study
    Cash Recycling
    CIBC
    Cloud
    Cloud Strategy
    Credit Card
    Crypto
    Cyber Security
    DEMPSTER-SHAFER MODEL
    EUROPE
    Fraud
    FRAUD DETECTION
    GREENLAKE
    HP
    HPE
    HP NonStop
    INTERNATIONAL
    LATIN AMERICA
    Legacy Replacement
    Lusis Payments
    Mastercard
    Mexico Office
    Microservices
    MIGRATION
    Mobile Payments
    NEWS RELEASE
    North America
    Payments
    Payments Industry Partners
    Payments Infrastructure
    PCI
    Philippe Preval
    Pivotal Payments
    POS
    PSD2
    Retail Payments
    Security
    Tandem User Group
    TANGO
    TANGO Cloud
    TANGO V8
    TEAM
    Technical Bootcamp
    The Connection
    Toronto
    Toronto Office
    User Profile
    Venmo
    Whitepaper
    Zelle

    RSS Feed

lusis payments processing
LUSIS SOLUTIONS​ FOR
Payments Processing
Payments Hub/Switch
ATM Management
Legacy Payment Replacement
Card Management
Apple Pay
Dynamic Currency Conversion
Mobile Payments
Loyalty Card
Artificial Intelligence
​FRAUD


LUSIS LITERATURE

PRIVACY POLICY

​LUSIS EVENTS
LUSIS NEWS
- Creating Enhanced Payments Agility
- Happy New Year! 2022 Highlights
- Banking on the Cloud

- Enriching the Branch Experience
- NEW: TANGO V8.1 with Cloud-Native Support
- A Reflection on Payments Fraud - 2022 and Beyond
- Is a revolution in consumer-centric payments inevitable?
- Changing the Payment Card Monopoly: What Does it Take?
- Is Russian software trustworthy?
- A Lusis Payments Reflection on 2021 ​
- Payments Q & A with Dave Smith
- Can financial services institutions rise to the challenge of FinTech?
- Infrastructure Decision Making - Five Key Principles 

- Preparing Your Payments Infrastructure for the Next Decade: A Guide for Financial Services Institutions
- Play to Win with TANGO for Retail Payments
- TANGO: Fast-Track to Cloud Payments
- Next Generation ATM Services
- Leading ATM Processor Chooses TANGO
- A new TANGO Benchmark on NonStop





- Why Companies are choosing TANGO to replace their Legacy Systems
​
- HPE GreenLake for Financial Payment Systems in Partnership with Lusis Payments​
- Leading Global Bank relies on TANGO for superior agility & impressive cost savings
​- Bayesian and Dempster-Shafer models for combining multiple sources of evidence in a fraud detection
- HPE NonStop for Lusis TANGO
- Cover story in "The Connection" magazine
   Tango V8 – An Implementation of Micro services 

- Fighting Fraud with the Latest Technologies TANGO AIF
- Lusis Payments Announces N American Support Center
- Research Chair: AI Applied to the Detection of Payment Fraud and Trading

- Lusis named Best Electronic Payment Systems
- Article:  A SME in the Big Leagues

​- ​TANGO 10K TPS in the Cloud
- Lusis Makes Strides to Revolutionize Payments Technology
- Lusis Leverages the Power of Artificial Intelligence
​- New Security Requirements for ATM and POS Introduced by PCI-PIN V3PIN V3: TR34 - TR31
​- TANGO - Stress Test on  HPE NonStop L-Series

- A Comparison of Machine Learning Techniques for Fraud Detection
HOME   |   TANGO   |   LITEPOS   |   SOLUTIONS   |   BENCHMARKS   |   ABOUT   |   WEBCAST   |   NEWS  
© 2022 Copyright Lusis Payments  
Lusis Payments, Lusis, TANGO and LitePOS are trademarks or registered trademarks of Lusis SA. Other parties’ trademarks referenced are the property of their respective owners.
  • Home
  • TANGO
  • AI FRAUD
  • LITEPOS
  • SOLUTIONS
    • TANGO VIDEOS
    • LITERATURE
  • BENCHMARKS
    • USER PROFILES
  • ABOUT
    • PARTNERS >
      • HPE GreenLake
    • VIDEO
    • EVENTS
    • PRIVACY
  • WEBCAST
  • Contact
    • CAREERS >
      • JOBS-UK
      • JOBS-FRANCE
      • JOBS-NA
      • JOBS-LA
      • JOB APPLICATION
  • NEWS
    • Market Insights
Proudly powered by Weebly