Polonious Integrations – Our Journey – part 3

Where we are now, where we’re going

Our REST APIs have enabled us to develop these rapidly, securely and cost-effectively.

Here are a few, and what we did to expand flexibility, most are completed, some current projects:

Fraud Detection Capabilities	GBG Instinct	We wrote an adaptor to use their XML Web services capabilities, their team wrote to our REST APIs.
	FRISS	We are writing a Spring Boot adaptor to take JSON about a claim and all of its details and create a case with all relevant details using our own REST APIs.
	Shift Technologies	We wrote a Spring Boot adaptor to take JSON about a referred claim and all of its details and create a case with all relevant details using our own REST APIs.
	Taylor Fry	Two-way integration with Taylor Fry’s Fraud analytics platform.
Case Information sources	CarFax – Vehicle History	We wrote a Spring Boot adaptor between requests in Polonious for Vehicle history and CarFax’s internal API. This returns a detailed car history as a PDF, textual information or both and adds them straight onto the case with a simple button click in Polonious.
	Social Discovery Corporation	We wrote code to interact with SDC’s team to begin a Social Discovery. The generated report is loaded back onto to the case once complete. User just clicks a button to request a Social Search for a Person on a case.
	TransUnion	We wrote a Spring Boot adaptor to connect to TransUnion’s search capabilities. We have integrated some of the more popular searches with a long term goal of covering the full range. These are configurable in the case view interface.
	Clear Data	We are currently working on this integration.
	Carpe Data	We wrote an integration to return social ‘hit’s from a person’s core information.
	Whooster	Public and Private Data Sources. Real-time Current and Historical. A proof of concept has been completed.
	Truepic	Truepic is the leading photo and video verification platform.
Video Interviewing	SimpleToConnect	We wrote code to talk to S2C’s REST APIs which means in the user interface we can provide video interviewing capabilities easily.
Claims Systems	Guidewire ClaimsCenter	We used the new DevConnect to talk ‘REST’ to and from the Guidewire Claims Center system. On a Claim, service requests can create cases in Polonious, all or some updates on the case can be returned to the Claims team via the DevConnect REST calls. Even documents and images can be shared, all seamlessly from both tools.
	Duck Creek	We’re currently working on this one.
Accounting Systems	QuickBooks	We integrate with Quickbooks REST APIs. This is now at the User Interface development point. Once complete, a more seamless creation of invoices and reconcilation interface will be available.
	Xero	We wrote REST APIs that help us integrate with Xero. This will use the same UI as the Quickbooks integration.
Link Analysis	I2 Analyst’s Notebook	We added GET capabilities around entities that i2 might need including cases, persons, addresses, organisations, assets and other entities. This allowed the i2 partner to develop a plugin using i2 plugin design tools in .NET. This integration is owned by the i2 partner.
	Maltego – Plugin	Polonious UK wrote a Maltego plugin that talks to Polonious given information like case numbers, persons and ‘expands the graph’ in Maltego using our REST APIs
Customer Integrations	Major Australian Bank	REST APIs to integrated with core services to facilitate case creation and updates from fraud analytics tools.
	Major NZ Insurer	REST APIs to integrate with their reporting systems written in Power BI. Customer did everything with minimal need from us other than the API documentation.Also a bespoke Guidewire integration using JMule written by their team to a v1 version of our create case REST api.
	Major US Insurer	Integration with their Claims platform via REST calls. Minimal involvement with our IT resources.
	Sales Force	Totally written by the Chinese IT team at a client site. This allows their sales reps to trigger a Brand Fraud case in Polonious when using a sales force mobile app in the field.
	Sumo Logic	Currently work in progress to deliver case outcomes back to sumo logic from triggered case.
Internal Polonious Integrations	AWS Amazon Cloud Automation	We wrote a comprehensive integration set that used our own REST calls to send and receive updates from automation of EC2/S3/VPC/RDS/IAM instance set up triggered from actions taken on cases in Polonious. Bizzare use-case but shows the capability well.
	Twilio	Text Messaging integration
	Google Authenticator	Mulit-factor Authentication Integration (work in progress)

Flexible Integration both ways – inbound and outbound

One of the core strengths of our case management system is that is is very flexible and adaptable to differing business needs. This is a great thing for our customers but a bit of a pain for the development team internally when adding features.

Every development sprint we do has to be predicated by the fact that we need to cover bases for all our customer needs now, and into the future.

Our REST APIs reflect this, and our future road map for them will take this a step further.

This final section is more for your IT teams to understand our approach and how it helps their efforts to integrate with our solution.

Create Case flexibility

Create Case is our most used API, it’s the gateway to initiating action inside Polonious for some trigger like Fraud detection or a referral from Claims.

This API has its own web interface to enable pretty much anything to be used as data to create a case. The interface allows a user to configure a mapping of inbound fields by uploading an example JSON. This JSON needs to be ‘flat’. ie the data has to be a single level of attributes. This actually covers off on 95% of our integration needs with the backup of additional REST services for the more complex cases where, for example, variable numbers of participants are involved.

Outbound REST Call flexibility

Our Polonious customers are now very familiar with the ability of Polonious to automate outbound integration tasks.

To achieve this, we often use a key transaction point in our application, the Case Note (or action, diary, update as some of our customers call it).

This means, you may want this integration to only happen at case inception, or at case review or case update, or possibly only at case close stages. Possibly at all of the above. Our Polonious Persons can configure this for you. No Polonious IT resources are usually needed.

How this works is fairly straight forward. For any type of case note, you can setup a REST call that can locate, collate and send any case data from that case (I mean any case data, including other diary entries, person, vehicle, company data from the case, any metrics gathered on the case either singular or as totals).

Our Polonious Configurers understand how to access the deep case data and can share many examples of how to use it with your team. The technique is pretty easy to use if you’ve used a templating/programming language before. This generally needs no input from our internal IT team reducing costs and speeding the process.

For complex integrations we use an adaptor

In many of the more complex needs, systems talk different protocols and need ‘cleansing’, selection or verification of data on the way to their penultimate system. To do this, we use microservice adaptors. These can be written by our teams at Polonious or your own IT teams. They can be written in any language your team is comfortable with. We have customers who have created these adaptors in languages other than Java such as python, c# and used them to talk to/from all sorts of different protocols like webservices, sftp,and the like.

The end point for this payload can be another system you’ve designed that talks any of the major security protocols or it can be an ‘adaptor’ web server written in any language (we prefer Java but some customers use node.js, .net, python and others. That adaptor can then forward the data (possibly after adapting it) to your internal applications in a way they understand.

Using an adaptor provides the additional benefit that the integration source code can be maintained separately from the core systems at either end. This makes updating and writing automated tests for it far easier. It also makes it much easier to understand to a new developer which improves maintainability and change cost. Due to the versioned APIs we use, this adaptor will not require regular updates to keep up with API changes.

Finally, an adaptor is just that – it can adapt more easily to internal security changes and other needs. We can easily send you more information (just by changing the payload with a quick call to our Polonious Persons. The rest is easy (excuse the pun), just a small change to the adaptor, re-run any tests, and you’ve updated your security or business requirements. You can change underlying systems with reduced pressures of dependencies as those dependencies are easy to maintain separately from the core systems.

If you are a Polonious client, we have a number of great examples we can share with you of this from our Spring Boot collection. This makes it really easy to stand up a new adaptor as and when needed.

The future

I hope this series has been interesting, it’s a good reflection of how we handle integration needs quickly and securely for on-boarding and existing customers. These are the takeaways that I hope you have seen demonstrated:

• Customer and product Integrations have improved markedly in the last 10 years in both speed and cost.
• Polonious have developed a great API-first approach to ensure most of your needs ready to be served.
• Most integration work at Polonious is done by the business-facing configuration teams, this saves time and money.
• The list of Polonious integrations is comprehensive and growing rapidly.

We are expecting a number of changes in the future to our current processes to make them easier to use, more robust, more secure. Currently we’re working on Spring Cloud services and integration technologies. We expect more flexible, scalable, secure and highly resilient services to come from this work.

Additionally, as the Insurtech space evolves, as more and more providers of case information come forward with great offerings, we intend to approach and integrate with all new information vendors as they arrive. To list a few we’d love to integrate with: NICB, Claims data providers, ebay, listings and other information providers.

Every piece of information an investigations team might want to access should be available at minimal effort to the team involved. No special interfaces, seamless integration available as simple button clicks is the way of future. Information sources that require special re-typing exercises will likely suffer in this changing landscape.

The future of case-related information at speed is looking great, we hope you enjoy the journey as much as we are.