RBA Cash Rate: 4.35% · 1AUD = 0.67 USD · Inflation: 4.1%  
Leading Digital Marketing Experts | 1300 235 433 | Aggregation Enquires Welcome | Book Appointment
Example Interest Rates: Home Loan Variable: 5.69% (5.89%*) • Home Loan Fixed: 5.49% (5.98%*) • Fixed: 5.49% (5.98%*) • Variable: 5.69% (5.89%*) • Investment IO: 5.79% (6.41%*) • Investment PI: 5.69% (6.55%*)

An Easier Way for Licence Holders, Aggregators, and Franchises to Manage Website Compliance Statements

An Easier Way for Licence Holders, Aggregators, and Franchises to Manage Website Compliance Statements

We've had an increasing number of businesses come to us that require a word-for-word privacy, terms, complaints (dispute resolution), and General Disclaimer on their website, and ACL holders are sensibly requiring the sea of websites managed by their credit representatives to be kept up-to-date. Once printed, these disclaimers are usually managed via a non-controlled email that might introduce changes, but very few changes are actually actioned by downline businesses. The net result is a very mild compliance infraction. What I'll do in this article is introduce a very simple method of creating a distribution channel that ensures broker statements (and the credit guide link) are always up-to-date.

We have our own module that'll enable brokers to update their privacy policies and credit guide reference in Yabber. However, the feature is one that manages individual policies, so the requirement to update the policy - regardless of how easy it might be - is still an action that needs to be performed. If you're a larger group using our systems, Yabber does provide for an update of all websites under your 'control', so this article is entirely irrelevant.

First, sharing always up-to-date compliance statements is just the start. Another article introduces how you might share content of any type, such as video, products, fact finds, forms, promotions, images, or dynamic 'widgets', to all broker websites associated with your group, with the powerful solution effectively emulating the functionality of our partner plugin (which is designed for partners of our clients).

Over 95% of all broker websites we've identified via the Matrix API are built on WordPress, so this makes inclusion of a plug-and-play website plugin the most logical solution, although we're required to provide alternatives for that small group using other platforms. We'll look at two simple methods.

  The Shortcode and Plugin Method

As long as a single source of data exists in a publicly accessibly location, we can query this endpoint, retrieve the data, then cache it on a website for a defined period of time. This endpoint might be the WordPress API, a custom API endpoint returning JSON, or a simple text file. For the sake of simplicity we'll look at retrieving a single (HTML) text file (the least desirable solution). The whole process is something they teach my 10-year-old daughter in basic Python classes at her school, and it is performed in just a few lines.

A single PHP function will do what we've described above. The file_get_contents() function is the most basic solution (again, the least desirable option in a production environment, but it works well for the purpose of a demo).

Requests Library: Requests in WordPress are normally made via the Requests library. The Requests Library permits a large number of options not available with file_get_contents(). The library forms the basis of all external requests made via our own client websites to any of our APIs.

The most basic implementation that'll render an external text file is as follows:

1
<?php 
2
echo file_get_contents('https://www.beliefmedia.com/dir/some-text-file.txt');

That's literally it. This single line will mitigate the headache associated with compliance statement variations across hundreds of websites. The text file will include HTML, links, images, a credit guide link, and any other assets that might be required. However, this code above isn't suitable for WordPress. Nor do you want a request made to the file every time the policy is viewed, so a simple shortcode function should be used. The function below includes placeholders for ACL, Credit Representative Number, Phone, Email, Website, Parent Website, ABN, and ACN (simply for the demo), but you could add as many placeholders as required. The placeholder data in the source file will be replaced with information specific to the broker making the request.

1
<?php 
2
/*
3
 BM Policy Shortcode
4
*/
5
 
6
function bm_get_policy($atts) {
7
 
8
 $atts = shortcode_atts(array(
9
 
10
  'cache' => 604800,
11
  'type' => 'privacy',
12
 
13
  'acl' => '123456',
14
  'crn' => '654321',
15
  'phone' => '1300 235 433',
16
  'email' => 'youremail@yourdomain.com',
17
  'website' => 'https://www.beliefmedia.com.au',
18
  'acl_website' => 'https://www.beliefmedia.com.au',
19
  'abn' => '98 987 654 321',
20
  'acn' => '987 654 321'    ), $atts);
21
 
22
 $t = md5(json_encode($atts));
23
 $e = get_transient($t);
24
 if ($e !== false) return $e;
25
 
26
 $d = file_get_contents('https://www.beliefmedia.com/some-directory/' . $atts['type'] . '.txt');
27
 if ($d === false) return 'Unavailable.';
28
 
29
 $fi = ['%%acl%%', '%%crn%%', '%%phone%%', '%%email%%', '%%website%%', '%%acl_website%%', '%%abn%%', '%%acn%%'];
30
 $re = [$atts['acl'], $atts['crn'], $atts['phone'], $atts['email'], $atts['website'], $atts['acl_website'], $atts['abn'], $atts['acn']];
31
 
32
 $r = trim(str_replace($fi, $re, $d));
33
 set_transient($t, $r, $atts['cache']);
34
 
35
 return $r;
36
}
37
add_shortcode('bm_policy', 'bm_get_policy');

The snippet would be used by your brokers by way of the shortcode snippet of [bm_policy type="privacy"] (where 'privacy' is the name of literally any text file that includes content of any type). The result would be cached for a full week on the client site before an update request is made (with timing altered by way of the 'cache' attribute). Of course, the snippet itself presents a technical challenge for brokers because they'd have to include the attributes each time the shortcode is used, so the inclusion of the code inside a plugin would be the most suitable option. A settings panel should be created for all of the data used in the find/replace function (the settings wouldn't be unlike the panel we use for clients to update their API Keys ).

Dynamic Replacement of Placeholders: In a real-world system, you would probably parse the incoming request for various parameters, such as a broker_id (?broker_id=123), and the information returned via the response wouldn't require any client-side processing to personalise the response. Data should ideally be manufactured server-side for each broker making the request.

Creating a plugin with just this function would take no longer than a minute, but we'd obviously include far more than just this function (details introduced in our article titled "An Easy Way for Larger Groups to Share Dynamic Website Content Across Multiple Websites "). The same article introduces how we manage the updates of plugins via our own self-hosted plugin repository.

  The JavaScript Method

Not all brokers use WordPress, so a simple JavaScript include might be considered as a global alternative. A single JS file should be created on your server as fetchTextFile.js or similar. The content might look as follows:

1
document.addEventListener('DOMContentLoaded', () => {
2
 const url = 'https://example.com/path/to/your/textfile.txt';
3
 
4
 fetch(url)
5
  .then(response => {
6
   if (!response.ok) {
7
    throw new Error('Network response was not ok');
8
   }
9
   return response.text();
10
  })
11
  .then(data => {
12
   document.getElementById('content').innerText = data;
13
  })
14
  .catch(error => {
15
   console.error('There has been a problem with your fetch operation:', error);
16
  });
17
});

A single JavaScript file would then be used on those websites requiring the feature.

1
<script src="https://example.com/path/to/fetchTextFile.js"></script>

A single snippet should be included where you would like the content to be shown.

1
<div id="content">Loading content...</div>

Only slight modifications would need to be made to include content of all types, and the caching would normally be determined by the CMS used by the broker. A simple function would normally be created to bypass the requirement for messy JavaScript.

  Conclusion

The tech we've introduced in this article is generally a poor solution that wouldn't be used in a scalable production environment. In reality, each aggregator, ACL holder, or larger business, would build its own API endpoints to return large amounts of dynamic data of all types, and the 'basic' solution is one that could be built with an administration dashboard in no longer than a few hours. It's not difficult, and it would serve content that would genuinely attract brokers to your operation.

I've mentioned a plugin option for brokers a few times because I see it as an essential service for brokers, and from an ACL perspective, it ensures that certain compliance-related elements are always maintained to the current version.

Some technology solutions take minutes to create and potentially save dozens of hours of manual oversight, and what we've described in this article is one such example.

  Featured Image: Australia’s first stock exchange, located at Collins Street, looking east from Queens Street, Melbourne, 1883. In the 18 October 1852 issue of the Argus, Edward Khull listed 14 companies in which investors could buy shares. This was the first stock listing in Australia and led to the formation of the Melbourne Brokers Association, which traded from rented space in the Hall of Commerce on Collins Street from 1859. It was Australia's first stock exchange. From The Argus publication in November 1856: "It has been the subject of constant and increasing complaint that while there are recognised marts and markets for every kind of produce, imported and otherwise, there is none for a larger and more important item in the wealth of the colony … there is no recognised Stock and Share Exchange, where quotations of stocks and shares could be made to show a real market value". The Stock Exchange of Melbourne grew out of and flourished in the economically tumultuous 1870s and 1880s when a huge influx of British capital flooded into 'Marvellous Melbourne'. It codified the behaviour of brokers, company listing requirements and trading processes. These practices remained unchanged for almost a century. The market contracted during the 1890s depression but grew again with the incredible success of mining in Broken Hill. This pattern of boom and bust drove the stock exchange through the first half of the 20th century but the stock market grew exponentially with the steady growth and diversification of the Australian economy after the Second World War. In 1987 the Melbourne Stock Exchange was absorbed into the new national trading body, the Australian Stock Exchange (ASX). Text Source: nma.gov.au. [ View Image ]

■ ■ ■

 
Download our complimentary 650-page guide on marketing for mortgage brokers. We'll show you exactly how we generate billions in volume for our clients.
Finance Guide, Cropped Top and Bottom
  Timezone: 1 · [ CHANGE ]

RELATED READING

Like this article?

Share on Facebook
Share on Twitter
Share on Linkdin
Share on Pinterest

Leave a comment