1) Creating an Entity Model for Fraud Prevention using Account Financial Transactions.

This Blog entry is from the Getting Started in Jube section in Learn Jube.

In this Blog entry an Entity model will be created to consume the Account Financial Transactions format with the objective of creating a fraud management platform.

Before proceeding with this Blog post, review the XML for the Account Financial Transaction in the formats document available at:

http://download.jube.io/formats.pdf

It can be seen that the XML is comprised of many elements that make up a financial transaction such as Amount, Location, Authentication Type etc. These elements can be added to in subsequent procedures and most will not be absolutely required:

1.PNG

Before embarking on this procedure, be sure to have read the Blog entries on messaging and integration and how to use the Postman page in Jube.

Fraud Prevention would be an Entity Model as it is classification rather than numeric prediction, in so far as the goal of the model is to classify a transaction as being either fraudulent of genuine.

Start by navigating to Entity Models >>> Entity Models

2.PNG

The Entity Models screen is where a model is first defined and allocated an EntityAnalysisModelGUID for model recall. Start by clicking on the Add button to expose the models basic parameters:

3.PNG

The parameters required for the creation of a new Entity Model will be displayed:

4.PNG

The tables as follows gives an introduction to each parameter available in Entity Model creation, excluding those explained in the Blog entries dealing with general user interface concepts:

Name

Description

This Example

GUID

When an Entity Model is created it is allocated a GUID (Globally Unique Identifier) which will be the key to the model upon it being recalled via the HTTP Endpoint. The recall of Entity Models is extensively documented in the HTTP Endpoint Request Payload and Switching section of this document. For example, the GUID is used in recalling the model via this endpoint as:

http://api.jube.io:5555?EntityAnalysisModelGUID=6b02e83e-f40f-4816-ad95-1329437b831b

TDB on Submission of new Entity Model

Message Type

The HTTP Request will likely contain a POST body (although it can accept data from only the Querystring). This parameter specifies if that HTTP POST Body is of XML or JSON format.

The parameter will be used to specify which parsing algorithm and schema to use, then whether the XPath parameters represent XML XPath or JSON JSONPath.

There is not much difference in parse or extraction performance between XML and JSON.

XML

Entity Name

The name of the field, as extracted from the HTTP POST Body or Querystring, that represents the entity identifier or key. An example of an Entity might be an Account identifier in the processing of financial transactions.

AccountID

Entity Payload Location

The Entity can be extracted either from the HTTP POST Body or the Querystring of the HTTP Request. This parameter specifies where the data is to be extracted from.

Body

Entity XPath

In the event that Body is specified for the Payload Location, the XPath or JSON Path specifying the location of the Entity in the HTTP Post Body. In the event that Querystring is specified for the Payload Location, the name of the Querystring as the key to the value collection in the list of Querystring values contained within the HTTP Request URL.

//AccountID

Entry Name

The name of the field, as extracted from the HTTP POST Body or Querystring, that represents the entry identifier or key. An example of an Entry might be a Transaction identifier in the processing of financial transactions.

TxnID

Entry Payload Location

The Entity can be extracted either from the HTTP POST Body or the Querystring of the HTTP Request. This parameter specifies where the data is to be extracted from.

Body

Entry XPath

In the event that Body is specified for the Payload Location, the XPath or JSON Path specifying the location of the Entity in the HTTP Post Body. In the event that Querystring is specified for the Payload Location, the name of the Querystring as the key to the value collection in the list of Querystring value contained within the HTTP Request URL.

//TxnID

Reference Date Name

The name of the field, as extracted from the HTTP POST Body, Querystring or using the current time, that represents the Reference Date. An example of a Reference Date might be the date time as of Now taken from the API endpoints system time.

TxnDateTime

Reference Date Payload Location

The Reference Date can be extracted either from the HTTP POST Body, the Querystring, the HTTP Post Request or taken from the system time of the API endpoint. This parameter specifies where the data is to be extracted from.

Body

Reference Date XPath

Subject to Now not having been specified for the Payload Location, the XPath or JSON Path specifying the location of the Reference Date in the HTTP Post Body. In the event that Querystring is specified for the Payload Location, the name of the Querystring as the key to the value collection in the list of Querystring value contained within the HTTP Request URL.

//TxnDateTime

Cache TTL Interval

When data is processed through an Entity Model it relies a subset or fast-moving data residing in a Mongo Database, known as the Cache. The interval is the time denomination which is used to specify the maximum amount of time that data should be resident in the cache before being purged and is taken together with Cache TTL Value.

Days

Cache TTL Value

When data is processed through an Entity Model it relies a subset or fast-moving data residing in a Mongo Database, known as the Cache. The interval is the number of intervals which is used to specify the maximum amount of time that data should be resident in the cache before being purged and is taken together with Cache TTL Interval.

30

Cache Fetch Limit

A limit applied on the retrieval of data from the cache set in order to avoid the real-time transaction processing being flooded by a very active entities (i.e. Accounts with an implausibly high number of transactions, such as test accounts). When retrieval is made from the Cache it is done so by selecting all records where there is a match on the Entity.

100

Enable Cache Entity

A toggle flag declaring if the model is to store events in the cache at all. It may be that the data volume is of such high volume that it is impractical to store and recall history data without needing to scale disproportionately.

True

Enable Cache Abstraction

After all processing has taken place, all calculations that were created as the result of processing are also stored in the cache to support the Abstraction Deviation functionality. This toggle flag declares the model capable of storing Abstraction in cache.

True

Enable Cache TTL Counters

TTL Counters are an alternative to storing all of the data in cache, instead only storing counter entries matching certain criteria. This toggle flag declares the model capable of storing TTL Counters.

True

Archive TTL Interval

The Archive relates to the storage of slow-moving data in support of analytics in the SQL Server database. The interval is the time denomination which is used to specify the maximum amount of time that data should be resident in the SQL Server Database before being purged and is taken together with Archive TTL Interval.

Days

Archive TTL Value

The Archive relates to the storage of slow-moving data in support of analytics in the SQL Server database. The value is the number of intervals which is used to specify the maximum amount of time that data should be resident in the cache before being purged and is taken together with Archive TTL Interval.

6

Mas Response Elevation

A value to truncate Response Elevations that are set to be higher than this value. It is commonly used in advertising technology to avoid over bidding.

11

Placing each one of the example values into their respective fields in the form:

1.PNG

Click the tick icon to commit the new Entity Model specification:

5.PNG

Confirmation that the Entity Model has been created will return in the form of a GUID having being created:

2.PNG

Allow the platform a few minutes to syncronise the new Entity Model with all of the endpoints, then navigate to the Postman page via Administration >>> HTTP Post Tools >>> Postman. Using the GUID, create a POST using the Account Financial Transaction XML to the https://api.jube.api endpoint.

Postman Paramater

Value

Format

XML

Querystring Pair Value Collection

EntityAnslysisModelGUID= f994ba45-1ef9-4af2-9164-870423e8e9d1

Request

Account Financial Transactions Taken from Formats document.

3.PNG

If Postman returns an XML document, echo back of several variables, it can be determined that Entity Model has been created and is now listening. The task now is to specify more elements to be extracted from the XML payload in the Request XPath page and as covered in subsequent Blog entries.