Use cases
Relavance FINSOFT™© (GPDR)
Trading companies typically have multiple trading software platforms in use. A major issue for compliance is there is no cross-platform compliance software- a trade may begin in one software and finalize in another.
Relavance FINSOFT solution gathers all trade data from all software, can connect to all the various protocols and codes, and can aggregate all the data into one data warehouse.
A user interface allows one to do historical research such as trade search and can integrate and use algorithms to evaluate for wash trades, snake trading etc. The compliance officer is then alerted to potential risks and can analyze deeper into the data, delegate to others to do research, then make a determination on the results.
The main points are:
1. Follow the real-time transactions of multiple Trading systems and monitor the flow between these systems
2. Intuitively seek any type of order
3. Simplify the audit for all changes
4. Enable Alerts and configure them in real-time, alert use algorithms to evaluate for wash trades, snake trading, etc. The compliance officer is then alerted to potential risks and can analyze deeper into the data, delegate to others to do research, then make a determination on the results.
5. Document the alerts through a process of validation.
6. Graphically view relevant information.
Case study for Electronic Patient Record system with IBM
1. The basic project, called 'arc en ciel', in the year 2000 was for IBM to implement an Electronic Patient Record (EPR) system that could be shared by all hospitals and clinics in Quebec.
Our 'assigned' part, as technology partner with IBM, was to manage non-text based data, X-rays, scans, etc. along with providing a telehealth service, enabling remote communities to have the benefits of highly qualified medical personnel able to review remotely taken images to assess the status and best treatment for the remote patients.
2. The company now Relavance and Medical Computer Inc. made a Joint Venture to solve the situation together with IBM where:
a. MedComp could transmit and store any picture and x-rays by remote control, under the specialists' control, on one of the first Telemedicine products in the market – Atlas TeleMed.
b. Relavance solved the privacy issue by enabling token references to each individual private patient record to be passed to IBM's central system, so the central system would know that the data regarding a particular patient resided at, say, hospitals X, Y, and Z, it thus could consequentially be shared when access was granted.
3. The main experience for Relavance was that we could ensure that clinical data was segregated from patient identifiable information and that the clinical data could be readily available in a compliant way for secondary use such as research and statistical purposes for Medical, Insurance and Pharmaceutical companies.
Case study: US Navy project (total provision system) 2003 – 2007
Initial Problem: Spare part system too slow and cumbersome to use for the Navy to reach its goal of being combat ready 65% of the time, which was a requirement set by US Congress.
Status at inception: Every ship needed to have required spare parts on board before leaving US Port A central legacy system provided wheelbarrows of Print-outs for the ships to know what they had on board and needed. There were over 70 million line items for assemblies, sub-assemblies and parts. Each with its specific 60 digit id number with specific history included. Thus when a spare part changed the name because of a new year model it also changed the part id number. Several companies including IBM had tried to come up with a solution spending a lot of time and money during the prior 15 years without success.
Basic Solution Our Associative technology identifies concepts with the same or different names as the same thing. So the same spare parts with different names were all of a sudden put together instead of being treated as separate parts before. This meant that they now needed much fewer parts onboard before departure and still could be combat-ready to a higher degree. Initially (2003) a “proof of concept” was successfully demonstrated, where most of the work was to understand the id numbering system.
Additional tasks Before the basic system was up and running for the Atlantic and the Pacific Fleet and servicing a total of 330 ships including several carriers, the Navy added new requirements and features to the system: system access authorization by whom and to what part of the system as well as workflow management.
Use of system “The associative database technology which is now named Relavance was a new technology we successfully applied to a long-standing problem on two Navy projects in the early 2000s. The two related projects, ReMAD and Smart ACHF, involved automation and modernization of systems supporting complex calculations and processes being done using 1970s mainframe technology. The challenge was to assimilate and track a large number of data changes across a data warehouse, sort through 50+ million records, and compute spare/repair part requirements for Navy ships – up to and including aircraft carriers. The challenge was complicated by different configurations of each ship based on incremental upgrades and changing versions of subsystems/parts, complex business logistics rules, and the sheer volume of data (billions of database-equivalent records).
A process that previously took more than a month of manual and semi-automated effort, was reduced to less than 15 minutes using the associative technology now at the core of Relavance. The long, labor intensive exercise became an automated, near real-time computation process – thanks to the power of associative database technology.”
Joe Homan
Program Director
Case Study: Fraud detection in a warranty program for a French Car Manufacturer
Initial problem: A French car manufacturer wanted to have better control of its warranty program and detect if there was any obvious fraud in the system.
Status at inception: Suspicions of abuse and fraud in the warranty program by management. The IT- Department could not quickly find a solution on how to compare reports from different markets with different languages and designations of car models and their spare parts.
Basic Solution: Categorize different car models by year as different concepts and thereafter assign all the different names in different languages to a concept, so that 1 car model and year could be called as many different names as needed. Thereafter all the parts for each model needed to be done the same way. Once this was done a database was created and used.
Reported findings: After being able to compare each model with its parts for all countries and dealers, one of the findings were that a specific dealer in Hungary stood out for reporting way too many battery warranty claims. The company later found that the dealer put in an old battery in all new cars and sold the new batteries that were delivered with the cars. Thereafter the customer claimed a warranty on the old battery and received a new battery.